便携式C++构建系统

Question

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

CMake的:

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

Boost.Jam:

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

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

Answer 1

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

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

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 - 它们仍然不如CMake成熟.

Answer 2

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

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

CMake,因为它是:

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

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

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

Answer 3

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

更新

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

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

Answer 4

我会在QMake上关注@Akusete,这是我现在选择的个人工具.优点和缺点也有点个人化,但在这里他们是:

优点:

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

缺点:

• 制造任意数量的目标有点自由.有一些预定义的,如app,lib等,但它是一个有点麻烦建立,比如,共享和静态库版本在单通或禁用预编译头为一个源文件.这绝对是可以实现的,但需要一些谷歌搜索,看起来很脏;
• 默认情况下绑定到Qt(通过添加QT -= core gui行很容易覆盖)

总体:

获得在简单到中等项目上快速完成的工作,但仍然留下"该死的感觉,它本来可以用更简单的方式完成!" 当应用于复杂的任务时.