便携式C++构建系统

Question

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

CMake：

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

F 213/code>

Boost.Jam：

solutions/projects

• (+)

• 本身没有中间步骤，

• (-)不会生成本机

• 简洁的语言，类似于经典的makefile

• (+)对多线程和静态/动态库

等属性的直观支持。

什么是其他的可能性，什么是真正更好的经验后？什么构建系统可以在途中创建一个解决方案？

Answer 1

(-)要求每个项目文件夹中都有一个配置文件

这是不正确的，你只需要通过更大的路径，例如：

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

很少有关于Boost.Jam的注释--首先，它本身并不是Boost.Jam - bjam本身，您正在寻找的是Boost.Build，它是一组使bjam有用的Jam宏。

现在，我与两者一起工作，我必须承认，Boost.Build不适合于任何严肃的项目之外的提升本身。需要找图书馆吗？不需要找到标题吗？不能。需要做一些简单的构建之外的事情-而你不知道如何将它作为BB文档.完全没用，也许能覆盖10%的BB。所以大多数情况下你需要在BB邮件列表中问问题.

因此，如果您有一些复杂的项目--您需要做一些比简单编译和链接更多的事情，请远离Boost.Build。

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

我不知道CMake是一个很好的系统，它有很多问题，但是它最适合跨平台开发(如果您需要支持MSVC)。

如果你不关心MSVC，也不喜欢MinGW.也可以看一下自动工具。

关于斯堪的纳维亚--他们还不太成熟，CMake。

Answer 2

这有点夸张，但我会尽量保持客观，只报告我的经历：

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

CMake是这样的：

(CMakeLists.txt)

• It用一种设计非常糟糕的免费格式(Makefile)取代了一种丑陋但形式化的格式(Makefile)，将其配置、缓存和其他杂乱无章的内容都转储到目录中，而不尊重用户保持源树干净的尝试。
• CMake的文档在大多数地方都是缺乏的(例如，尝试将源目录递归地添加到目标wile中，不包括某些starters文件)
• 生成的CMake项目非常糟糕(有一个结构良好的Visual项目吗？)CMake将将所有源代码转储到单个项目节点)
• 生成的
• 项目使用绝对路径(因此您不能将它们签入源代码管理--每个人都必须使用CMake)，只能在平台之间选择
• (例如。( x64和x86)在生成项目/生成文件时。CMake不会生成支持多个平台的项目，即使IDE对此非常满意。
• 很少控制如何引用库。有一系列的引用查找方法(所以即使在控制不好的情况下，您也不能期望whatsoever).

的一致性)。

我个人的观点是，即使有人有意设计最糟糕的跨平台构建系统，也很难做比CMake更糟糕的事情。

我对Boost.Build没有任何经验，它很可能也有同样严重的缺点，但关于CMake，我能说的最好的是，如果您只关心以某种方式构建一些源文件，它就可以完成任务--尽管对开发人员和库/应用程序使用者来说会带来很大的痛苦。

Answer 3

我对premake4：http://industriousone.com/premake有过一些很好的体验

更新

我仍然喜欢预制片，但经过一段时间的工作后，我觉得有义务列出我在其中发现的一些缺点：

不支持

• 集成新的工具链(即bison或moc等预处理工具)。不支持每个文件的configuration.
• Library查找是不灵活的，不支持脚本或版本checking.
• Some指令(例如配置)会影响以下语句，但没有明确的范围划界。这会导致微妙的错误。
• 很少支持调试配置，换句话说，除了检查生成的构建脚本或运行它们之外，还可以显示配置是如何被解释的。对于gmake，
• 至少没有使路径为绝对的选项。这并不适合Vim的快速修复，尽管它很容易解决。
• 的开发速度缓慢。新特性可以开发多年。