跨平台库答案

【问题标题】：Cross-platform Library跨平台库
【发布时间】：2023-03-10 23:10:02
【问题描述】：

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

我应该澄清一下，当我说“跨平台”时，我主要关心的是针对多 CPU 架构 (x86/x86_64/ARM) 进行编译。

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

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

我想到了两种可能的解决方案：

包括为每个平台编译的静态库。
继续包含源代码。

我确实对上述两个选项都有保留。选项 1 似乎过于复杂/浪费。选项 2 似乎是不好的做法，因为每个项目都可能修改“库”并变得不同步；特别是如果库源代码与所有其他项目源代码存储在同一目录中。

如果您提供有关如何解决此问题的任何建议，或者有关其他人以前如何解决此问题的信息，我将不胜感激？

【问题讨论】：

您有多个平台。构建一个公共库，无论是共享的还是静态的，几乎没有什么区别。就像您的项目代码一样，您的公共库也必须为每个平台构建。没有转义（除非像 C++ 模板头文件库这样的东西，它没有平台相关的图像，因为它是在编译客户端代码期间引入的）。
谢谢，我明白了。正如我所说，我可以为不同的平台预编译静态库。但是，我想知道是否有人可以推荐一个简洁的解决方案。

标签： c cross-platform static-libraries

【解决方案1】：

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

【讨论】：

感谢您的回复。我想这会更适合共享对象？老实说，我试图让用户不必执行多个make、make install。
在这种情况下，您可以提供二进制文件。当然，这意味着您每次都必须针对多个平台进行编译，但这可以自动化。在 x86-64 机器上为 x86 构建通常很容易，您只需要一个 32 位工具链。要生成 ARM 二进制文件，您可以拥有一个带有虚拟机的 ARM 模拟器，其中您有一个脚本，该脚本可以获取源代码、编译、返回二进制文件（或错误消息，如果您不走运，但您会无论如何都需要修复它）。
谢谢。我很欣赏你的说法，并且知道这就是一些项目的运作方式。但这似乎是不必要的复杂和有些浪费？
这完全取决于用例。为什么你想让用户不必构建你的库？假设您的源代码解压到名为mylib 的文件夹中，他们所要做的就是将此文件夹复制到他们的源代码树中，并将类似cd mylib && make 的内容添加到他们的Makefile 中，这在他们的项目生命周期中恰好一次。真的有那么大的努力吗？
抱歉，我想我们混淆了“用户”这个词；我指的是最终用户。所以，如果我要采用这个模型，并将mylib 复制到源代码树中。您能否详细说明如何组织父项目的源代码树（目录结构）？