关于如何部署 C++ 代码以在任何地方工作的提示

Question

我不是在谈论制作可移植代码。这更多的是分配问题。我有一个中型项目。它对公共库有几个依赖项（例如 openssl、zlib 等）。它在我的机器上编译得很好，现在是时候将它公之于众了。

本质上是构建最好的工程。我想为 Windows、Linux、MacOSX 等制作安装程序。我想制作一个可下载的 tar 球，它可以使代码与 ./configure 和 make 一起工作（可能通过 autoconf）。拥有一个可以构建安装程序的 make 选项将是锦上添花。甚至可以交叉编译，以便可以在 Linux 中构建 Windows 安装程序。

什么是最好的策略？我可以期望在哪里度过最多的时间？主要关注点应该是 autoconf 还是有其他可以提供帮助的工具？

Answer 1

我从事的产品与此并无太大不同。我们使用基于 autoconf 的构建系统，它运行良好。

到目前为止，您将花费最多时间的地方是支持用户。用户系统会有各种各样的皱纹，除非它们遇到它们，否则您将需要添加更多配置选项来支持它们。随着时间的推移，我们添加了为我们所依赖的每个库设置包含和库路径的选项；我们添加了更改编译标志的选项，以解决这些库的各种版本中的各种奇怪故障（或 API 从一个版本更改为另一个版本，而不是我们的代码需要更改），我们添加了一些解决方法，因为某些 BLAS 库使用 C 接口，有些使用 Fortran 接口，所以即使它们在理论上是同一个库的实现，但它们做的一些事情略有不同，等等。您无法提前预料到这一切，而且还需要记录，以便用户可以确定要设置哪些选项。

哦，安装程序真的很痛苦，因为它们通常依赖于操作系统（除非它只是一个 shell 脚本并且您需要 CygWin），而且要安装的位置往往依赖于操作系统，等等。这是另一个需要时间的领域——无论是构建一个好的安装程序，还是支持用户手动设置。

根据我的经验，设置交叉编译是值得的（至少对于 Linux 到 Windows 的情况；不确定 MacOS/X）——比尝试在其中保留多个不同的构建系统容易得多同步。

作为另一种观点，OpenFOAM 项目为他们相当大的 C++ 库使用了一个选项，即将它与“批准”的 G++ 编译器和所有其他组件的包一起分发，这样他们就不会不得不担心不同的编译器等等。但这实际上只适用于一个操作系统。我猜它的 Windows/MacOSX 版本是提供预先设置的 VMWare 映像。在某些情况下，有话要说......

Answer 2

使用自动工具，大多数用户都熟悉它们（即他们知道运行 ./configure && make && make install）

• 使用 make dist 创建 .tar.gz，对其进行测试以确保它可以在多个系统上编译和工作。

• 对于 Linux/Unix/Cygwin，不提供安装程序... source tar.gz 就更好了。在任何情况下，每个 Linux 发行版都有自己的打包规则，并且大多数都知道使用 autoconf 构建，用户可能拥有 32 位或 64 位系统，甚至运行 PPC 或 Sparc - 所以不要打扰。

  也许值得为最流行的系统创建一个 deb 或 rpm，但仅此而已..

• 对于 Windows（本机，而不是 cygwin）提供二进制文件。安装 Migw+auto 非常痛苦，windows 用户通常更多的是 "next->next->next" 用户然后 "wget/tar/configure/make/make-install" 用户" 提供 zip 或一些安装程序 还有一些 FOSS 安装程序在那里。

  请记住，糟糕的 Windows 用户默认没有 zlib 或 openssl...所以您需要将它们与您的软件包一起提供。

关于 CMake...

如果您主要针对 Windows 平台，或者您愿意支持 MSVC，那么您可能应该考虑它。否则，自动工具会提供良好的分发和构建替代方案。

Answer 3

我会推荐CMake。优点：

• 使用它非常容易使用静态库、动态库、可执行文件及其依赖项构建简单和复杂的项目。
• 它独立于平台，可为大多数编译器和 IDE 生成 makefile 和/或 ide 项目文件。
• 它抽象了 windows 和 unix 之间的差异，例如“libShared.so”和“Shared.dll”被称为“Shared”（cmake 处理每个平台的名称差异），如果 Shared 是您项目的一部分，它如果不是，则对依赖项进行排序，它假定它位于链接器路径中。
• 它会调查用户系统中所需的编译器和第 3 方库，然后您可以选择在第 3 方库不可用时删除组件或显示错误消息（它附带宏以查找最常见的第 3 方库）。
• 它可以从命令行运行，也可以使用简单的 gui 运行，使用户能够更改上面发现的任何参数（例如编译器或第 3 方库的版本）。
• 它支持用于自动执行常见步骤的宏。
• 有一个叫CPack的组件可以让你创建一个安装程序，我想这只是一个make install命令行的东西（我没用过）。
• CTest 组件与其他单元测试库（例如 boost test 或 google test）集成。

我现在对所有事情都使用 CMake，甚至使用 Visual Studio 进行简单的测试项目。

我从未使用过自动工具，但许多其他用户评论说 cmake 更易于使用。出于这个原因，KDE 项目从 autotools 转移到了 cmake。

Answer 4

尝试使用cqtdeployer。该实用程序可以搜索和收集应用程序的所有依赖项，并为其创建安装程序。

使用示例：

cqtdeployer -bin myApp deploySystem

CQtDeployer 在 snap-store 和 GitHub Releases 上可用。但是 snap 版本不适合部署系统库。因此，您只需要使用 GitHub 上安装程序中的版本即可。

您还可以创建安装程序，将 qif 选项添加到末尾。

cqtdeployer -bin myApp deploySystem qif

执行后，得到如下形式的安装程序：

此实用程序可以在 Windows 和 Linux 上运行。选项集在所有平台上都是相同的。

如果您的项目包含许多库，则使用 libDir 和 recursiveDepth 选项。这将允许 cqtdeployer 找到您的其他库。

cqtdeployer -bin myApp deploySystem qif -libDir /path/to/my/Libs -recursiveDepth 5

欲了解更多信息，请阅读项目wiki。