代码之家  ›  专栏  ›  技术社区  ›  User1

关于如何部署C++代码以在每个地方工作的技巧

  •  18
  • User1  · 技术社区  · 14 年前

    我说的不是制造可移植代码。这更像是一个分配问题。我有一个中型项目。它与公共库(如openssl、zlib等)有几个依赖关系。它在我的机器上编译得很好,现在是时候把它交给世界了。

    从本质上说,建造工程是最好的。我想为Windows、Linux、Macosx等制作安装程序。我想制作一个可下载的tar-ball,使代码能够与 ./configure 和A make (可能通过autoconf)。如果有一个make选项来构建安装程序,那将是锦上添花。甚至可以交叉编译,以便在Linux中构建Windows安装程序。

    最好的策略是什么?我可以期望在哪里花费最多的时间?主要焦点应该是autoconf还是有其他工具可以帮助?

    3 回复  |  直到 14 年前
        1
  •  17
  •   iain    14 年前

    我建议你 CMake . 优势:

    • 使用静态库、动态库、可执行文件及其依赖项构建简单和复杂的项目非常容易。
    • 它独立于平台,为大多数编译器和IDE生成makefiles和/或ide项目文件。
    • 它抽象了Windows和Unix之间的差异,例如“libshared.so”和“shared.dll”被称为“shared”(cmake处理每个平台的名称差异),如果shared是项目的一部分,它会对依赖项进行排序,如果不是,则假定它在链接器路径中。
    • 它调查用户系统中所需的编译器和第三方库,然后您可以选择在第三方库不可用时删除组件或显示错误消息(它附带宏以查找最常见的第三方库)。
    • 它可以从命令行运行,也可以使用一个简单的图形用户界面运行,该界面允许用户更改上面发现的任何参数(例如编译器或第三方库的版本)。
    • 它支持宏来自动执行常见步骤。
    • 有一个名为cpack的组件可以让您创建安装程序,我认为这只是一个 make install 命令行内容(我没有使用它)。
    • CTest组件与其他单元测试库集成,如Boost测试或Google测试。

    我现在对所有东西都使用cmake,甚至是使用Visual Studio的简单测试项目。

    我从来没有使用过自动工具,但很多其他用户评论说,cmake更容易使用。因此,kde项目从autotools移到了cmake。

        2
  •  3
  •   Brooks Moses    14 年前

    我工作的产品和这个没有太大的不同。我们使用一个基于autoconf的构建系统,它工作得很好。

    到目前为止,您将花费最多时间的地方是支持用户。用户系统将有各种各样的皱纹,直到遇到它们时你才预料到,你需要添加更多的配置选项来支持它们。随着时间的推移,我们添加了一些选项来设置我们所依赖的每个库的include和lib路径;我们添加了一些选项来更改编译标志,以解决这些库的不同版本中的各种奇怪的错误(或者API从一个版本更改为另一个版本,而不需要更改代码),我们增加了一些解决方法,因为一些BLAS库使用C接口,一些使用Fortran接口,所以即使理论上它们是同一个库的实现,它们也会做一些稍微不同的事情,等等。您不能预先预料到这一切,它还需要文档化,以便用户能够确定要设置的选项。

    哦,安装程序真的很麻烦,因为它们通常依赖于操作系统(除非它只是一个shell脚本,而您需要cygwin),安装位置往往依赖于操作系统,等等。这是另一个需要花费时间的领域——要么在构建一个好的安装程序,要么在支持用户手动设置方面。

    根据我的经验,设置交叉编译非常值得麻烦(至少对于Linux到Windows的情况,不确定MacOS/X),这比尝试保持多个不同的构建系统同步要容易得多。

    作为另一种观点,OpenPo沫项目使用的选项是它们相当大的C++库,它将与一个“批准的”G++编译器一起分发,并为所有其他组件打包,这样它们就不必担心不同的编译器等等。但这只适用于一个操作系统。我想Windows/MacOSX版本是为了提供预先设置的VMware映像。在某些情况下,有话要说……

        3
  •  0
  •   Artyom    14 年前

    使用自动工具,大多数用户都熟悉它们(即,他们知道如何运行/配置&制作&制作安装)

    • 用make dist创建.tar.gz,测试它,确保它编译并在多个系统上工作。
    • 对于Linux/Unix/Cygwin,不提供安装程序…源tar.gz比好。在任何情况下,每个Linux发行版都有自己的打包规则,其中大多数都知道要使用autoconf构建,用户可能有32或64位系统,甚至可以运行ppc或sparc,所以不用担心。

      也许为大多数流行的系统创建一个DEB或RPM是值得的,但不会比这更多。

    • 对于Windows(本机,而不是Cygwin),请提供二进制文件。安装migw+auto非常痛苦,Windows用户通常更多地是“下一步”->下一步是“用户”,然后是“wget/tar/configure/make/make install”users“提供zip或某些安装程序有一些FOSS安装程序。

      请记住,默认情况下,较差的Windows用户没有zlib或openssl…所以你需要把它们和你的包裹一起装运。

    关于CMAKE…

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