C 跨平台图书馆

基本上，我希望将现有项目中的一些常见功能分离到一个单独的库项目中，但在包含此库时，也允许项目保持跨平台

我应该澄清一下，当我说“跨平台”时，我主要关心的是针对多CPU体系结构（x86/x86_64/ARM）的编译

我有一些有用的功能，我在我的许多软件项目中都使用这些功能。所以我决定在项目之间复制这些源代码文件是不好的做法，我应该创建一个独立的库项目

我认为静态库比共享库更适合我的需要。然而，我突然想到，静态库将依赖于平台，通过将其包含在我的项目中，将导致这些项目也依赖于平台。与包含源代码本身相比，这显然是一个缺点

我想到了两种可能的解决办法：

包括为每个平台编译的静态库

继续包含源代码

我对以上两种选择都有所保留。选项1似乎过于复杂/浪费。选项2看起来像是坏习惯，因为每个项目都可能修改“库”并变得不同步；尤其是如果库源代码与所有其他项目源代码存储在同一目录中

---

如果您能就如何克服此问题提供任何建议，或提供其他人以前如何克服此问题的信息，我将不胜感激。

您可以采用开源项目的标准方法（即使您的项目不是开源项目）。有一个中心点可以获取源代码，大概是在版本控制下（subversion，git…）。任何想要使用这个库的人都应该检查源代码，编译它（应该包括一个Makefile或类似的东西），然后它们都被设置好了。如果有人需要更改库中的某些内容，他们会这样做，测试他们的更改，并向您发送修补程序，以便您可以将更改应用到项目中（或不应用，取决于您对修补程序的意见）。

感谢您的回复。我想这更适合共享对象？老实说，我试图让用户不必执行多个

make

，

makeinstall

。在这种情况下，您可以提供二进制文件。当然，这意味着您每次都必须为多个平台编译，但这是可以自动化的。在x86-64机器上构建x86通常很容易，您只需要一个32位的工具链。要生成ARM二进制文件，您可以使用一个带有虚拟机的ARM仿真器，其中有一个脚本，用于获取源代码、编译并返回二进制文件（或者错误消息，如果您运气不好，但是您仍然需要修复它）。谢谢。我很欣赏你的话，我知道有些项目就是这样运作的。但它似乎不必要地复杂，而且有些浪费？这完全取决于用例。为什么您希望用户不必构建您的库？假设您的源代码解压到名为

mylib

的文件夹中，他们所要做的就是将此文件夹复制到他们的源代码树中，并将类似

cd mylib&&make

的内容添加到他们的Makefile中，在项目生命周期中只添加一次。这真的那么费劲吗？对不起，我想我们混淆了“用户”这个词；我指的是一个终端用户。因此，如果我采用这个模型，并将

mylib

复制到源代码树中。您能否详细说明如何组织父项目的源代码树（目录结构）？您有多个平台。构建一个公共库，无论是共享的还是静态的，都没有什么区别。就像您的项目代码一样，您的公共库也必须为每个平台构建。无法避免（禁止像C++模板头库那样的东西，因为它在编译客户端代码时没有依赖于平台的图像）。谢谢，我确实理解。正如我所说，我可以为不同的平台预先编译静态库。然而，我想知道是否有人可以推荐一个简洁的解决方案。