便携式C ++构建系统

时间:2010-07-28 04:28:53

标签: c++ build-process portability

我正在为C ++项目寻找一个易于维护的便携式构建系统。主要平台应包括Windows(Visual Studio 8+)和Linux(gcc); Cygwin可能是一个优势。我们正在考虑两种主要可能性: CMake Boost.Jam 。 SCons也可以选择,但我还没有调查过。 CMake和Boost.Jam似乎具有以下特征:

CMake的:

  • (+)生成本机“makefile”(Windows解决方案,Eclipse项目)
  • (+)扩展程序用于测试和打包
  • ( - )要求每个项目文件夹
  • 中的配置文件
  • ( - )基于一种过于冗长的特殊语言

Boost.Jam:

  • 自行构建,没有中间步骤
  • ( - )不会生成原生解决方案/项目
  • (+)简洁的语言,类似于经典的makefile
  • (+)直观支持多线程和静态/动态库等属性

有什么其他可能性以及经验之后真正优先考虑的是什么?什么构建系统可以在途中创建解决方案?

4 个答案:

答案 0 :(得分:15)

  

( - )需要每个项目文件夹中的配置文件

这是不对的,你只需要传递更大的内容,如:

add_program(foo src/foo.cpp src/main.cpp)

很少有关于Boost.Jam的说明 - 首先它不是Boost.Jam - bjam本身相当无用,你正在寻找的是Boost.Build,它是一组Jam宏,它使bjam变得有用。

现在,我与两者合作,我必须承认,Boost.Build不适合Boost本身以外的任何严肃项目。需要找到图书馆?不需要找头?不能。需要做一些简单构建之外的东西 - 你不知道怎么做它作为BB文档...完全没用,可能覆盖BB的10%。因此,大多数情况下你需要在BB邮件列表中提问并......

所以,如果你有一些复杂的项目 - 你需要做更多的事情然后简单的编译和链接,远离Boost.Build。

因此,如果您需要支持MSVC,我今天发现CMake是唯一可行的选择。

我不是说CMake是非常好的系统,它有很多问题,但它是一些东西 主要适用于跨平台开发(如果您需要支持MSVC)。

如果您不关心MSVC并对MinGW感到满意......请看一下autotools。

关于Scons - 它们仍然不那么成熟了。

答案 1 :(得分:13)

这有点咆哮,但我会尽量保持客观,只报告我的经历:

我已经尝试了几次CMake,我已经接近达到这样的程度,我将自愿为每个构建环境维护单独的项目文件或滥用其他语言的构建系统(Ant,NAnt,MSBuild等)来编译并打包我的C ++项目。

CMake,因为它是:

  • 它取代了一种丑陋但形式化的格式(Makefile),其格式设计得非常糟糕(CMakeLists.txt)
  • 它会在整个目录中转储其配置,缓存和其他混乱,而不尊重用户尝试保持源树清洁。
  • 大多数地方缺少CMake的文档(例如,尝试以递归方式将源目录添加到目标文件中,不包括某些文件的初学者)
  • 生成的IDE项目非常差(具有结构良好的Visual Studio项目?CMake会将所有源转储到单个项目节点中)
  • 生成的IDE项目使用绝对路径(因此您无法将它们检入源代码控制 - 每个人都必须使用CMake)
  • 您只能在生成项目/生成文件时在平台之间进行选择(例如x64和x86)。即使IDE完全没问题,CMake也不会生成支持多个平台的项目。
  • 很少控制库的引用方式。有一系列的参考发现方法(所以即使控制不佳,你也可以期待没有任何一致性。)

我个人认为,即使有人想故意设计最糟糕的跨平台构建系统,也很难比CMake更糟糕。

我对Boost.Build没有任何经验,它可能也有同样严重的缺点,但我能说的关于CMake的最好的方法是,如果您唯一关心的是以某种方式构建的某些源文件,它可以完成工作 - 尽管开发人员和图书馆/应用程序消费者都有很多痛苦。

答案 2 :(得分:9)

我在premake4上有过一些很好的经历:http://industriousone.com/premake

<强>更新

我仍然喜欢预制,但经过一段时间的努力,我觉得有必要列出我在其中发现的一些缺点:

  • 不支持集成新工具链(即bison或moc等预处理工具)。
  • 不支持每个文件配置。
  • 库查找不灵活,不支持脚本或版本检查。
  • 某些指令(例如配置)会影响以下语句,但没有明确的范围分隔。这可能会导致细微的错误。
  • 支持调试配置,换句话说,显示如何解释配置,而不是检查生成的构建脚本或运行它们。
  • 至少对于gmake Makefiles,没有选择让路径绝对。这与Vim的quickfix不太匹配,虽然它很容易解决。
  • 发展步伐缓慢。新功能可以在年开发

答案 3 :(得分:5)

我会在 QMake 上关注@Akusete,这是我现在选择的个人工具。利弊也有点个人化,但在这里它们是:

优点:

  • 与CMake相比,更简洁的脚本语言;
  • 可以在Windows上生成VS项目和jom兼容的makefile;
  • 为交叉编译添加工具链非常简单(归结为使用相同mkspec语言编写的自定义qmake);

缺点:

  • 制造任意数量目标的自由度有限。有一些预定义的,例如applib等,但是在一次传递中构建共享和静态库版本或者为单个源禁用预编译头文件有点麻烦文件。这绝对是可以实现的,但需要一些谷歌搜索并且看起来很脏;
  • 默认绑定到Qt(可以通过添加QT -= core gui行轻松覆盖)

总体:

快速完成简单到中等项目的工作,但仍然留下了“该死的感觉,它可以以更简单的方式完成!”应用于复杂的任务时。

相关问题