C ++构build系统

我已经使用了SCons一年多了，真的很酷。 这是一个完整的构建系统，而不是构建脚本生成器。

它是基于Python的，你可以用Python编写SConstruct和SConscript（相当于Makefile），允许你调用你想要的任何可用的库，以及Makefile授权的更清晰的语法。

由于Python是跨平台的，SCons也是如此，在那里没有问题。

它捆绑了很多目标：

• 检测到可用的二进制文件，并自动将许多扩展名映射到正确的二进制文件
• 根据操作系统检测对象/库的正确扩展名，尽管您可以覆盖它
• 为移动，复制，焦点提供常用操作的设施（在构建之后被延迟），并且您可以提供自己的Python脚本并挂钩它们
• 开箱即用，但在每个级别上都提供了许多定制化的钩子

这是非常有效的，甚至提出了高级功能（如将预处理文件的散列存储在sqlite数据库中，而不是使用时间戳），即使您最终决定了策略。

它还提供免费的依赖项循环检测（肯定没有Makefiles的东西），界面通常只是更好/自动化。

我说这是有效的吗？ 那么它显然允许多个作业并行执行;）

而且它也是免费的，就像免费饮料一样，随时可以贡献;）

我只能推荐它。

我没有与其他人的经验，但如果你正在寻找一个跨平台的交叉工具链构建系统，使用CMake。 CMake实际上并不是一个构建系统，它是一个构建脚本生成器 – 它为许多构建系统生成了实际的构建脚本，而且（在我看来，这是强大的）为Visual Studio和KDevelop等主要IDE生成项目文件。 最近的KDevelop版本，顺便说一下，有CMake文件的Intellisense。

生成的构建脚本或Visual Studio解决方案不像手动创建时那样优雅，但是由于您也不必手动维护它们，所以很好。

CMake的不足之处在于它并不是真的带有很多内置工具，或者是一个简单的扩展方法（比如MSBuild，当然这只是一个构建系统，而不是一个生成器）。 我们的Linux开发人员倾向于调用Unix命令行工具来执行诸如压缩/解压缩之类的东西，这在典型的Windows安装中是不可用的，而MSBuild从社区项目中可以获得数以千计的附加命令，所以您不需要使用命令行，为MSBuild创建一个新的任务非常简单。 我目前正在研究如何解决CMake的这些限制，因为它目前意味着我们不能完全在Windows上构建，尽管代码本身可以很好地构建。

编写CMake文件不是一个美丽的体验，但没关系。 这个语言有一些奇怪的怪癖（比如不得不在else和endif中重复一个if条件，这会让你特别在试验时变得疯狂），而且真的很讨厌在每个文件中都有一个名为CMakeLists.txt的文件，每个具有自定义构建规则的目录（在一个大型的项目中可能还有很多），并且它们全都在IDE中显示出来;）

未来几年…

• 从我所看到的， SCons正在流行起来。 我根本不喜欢它。
• Waf真棒（在我看来）。 如果您正在研究SCons，请先尝试Waf。 但是，并行构建会始终显示所有发生的错误…因此，期待屏幕上充满错误消息。 而且，扩展可能会有点复杂。
• Boost.Build是我的最爱之一，但却是地球上最糟糕的文档。 除此之外，它非常灵活，可以让你做任何事情。 有时候可能有点慢。
• CMake只适用于生成忍者脚本; 其他任何东西都是垃圾（1行1个可执行项目的4000行makefile）
• Tup很好，但是缺少配置的东西。
• Autoconf仍然是autocrap 。

其他未提及的：

• Kbuild是一个有点古怪，但看起来不错。 这是我所知道的一切。
• mk-configure非常适合做恋人。
• 用shake-language-c来动摇是非常灵活的，可以让你做任何事情…如果你了解Haskell并且不介意放弃VS的支持。
• Jamplus喜欢在每一个令人厌烦的编译器命令结束时将-m32 移到 64位系统上。
• 苔原可以是一个重复，但仍然非常快速和准确。
• Bam … Tundra更好。 它速度快，不会牺牲准确性。
• Gyp （用于Google Chrome / Chromium）没有记录，但是是CMake的一个很好的选择。
• 如果你珍惜简单， Premake是非常棒的，但是当它看起来很简单的时候，它会变得烦人。
• Bakefile是非常有限的，但对于简单的项目来说非常有用 。
• fbuild是我最喜欢的（与Boost.Build一起）。 这是相当没有文档，但有很多的例子和非常可读的源代码。 生成脚本也很短。 它被用来为Felix构建（并且被设计）。 它也非常非常快，而且几乎总是非常准确，并且具有自动并行性，不会使您的屏幕泛滥。 永远。 我正在使用它来构建一个正则表达式JIT引擎，我非常高兴。 这也很容易扩展。 不过，从技术上来说它还处于测试阶段，尽管我从来没有遇到过任何真正的问题。

如果你喜欢makefile生成器，我建议使用fbuild或者Boost.Build …或者Gyp。

如果你想扩展基本功能，绝对使用fbuild。 如果你有很多平台特定的标志/选项和大量的混乱，使用Boost.Build。 如果你需要一个makefile生成器或有大量的配置，请尝试Gyp。

我有机会自己比较所有这些。 首先我们使用make 。 这是丑陋的。 你必须让专家真正了解发生了什么事情。 我不会再次痛苦。

然后我们搬到了SCons 。 它的语法是好的，你仍然可以做丑陋的事情，因为你可以编写自己的脚本，往往是程序。 这给了你很大的灵活性。 但是我们踢了SCons，因为我们不得不等待大约20秒的时间进行项目扫描，而每次都要等20秒。 然后我的大学写了python代码来将其扫描结果缓存到文件中，性能几乎翻了一番。 当你添加一个文件或从项目中删除一个文件时，你必须等待大约20秒的时间来构建，你必须重新运行一个–fill-cache参数。

然后我把项目移到了CMake上 ，这肯定是我选择的工具。 它的结构和语法非常好可读，也有文档记录。 它为您生成几乎所有IDE的项目，并且早期支持市场上的新IDE。 构建过程与IDE一样快，只需要添加新项目或更改项目属性以保留CMake时，就只需返回到CMake

所以我会建议CMake

另一个工具是TUP 。 这个工具我的经验非常好。 托普

• 自动处理依赖关系（不需要调用gcc -M）。
• 适用于部分依赖关系图，因此速度非常快 。
• 它以辉煌的方式支持递归目录结构（Tuprules.tup）
• 以出色的方式支持git：可以根据目标列表自动创建.gitignore文件。
• 非常容易使用，Tupfiles的语法非常简单。
• 它保持源文件的一致构建，即使您重命名文件或删除文件。 因此，构建的二进制文件总是反映源的当前状态。 这也意味着，你永远不需要清理你的项目。

在用于两个相当复杂的项目之后，我只能说一件坏事：

• 与ClearCase动态视图一起使用很复杂。

看看Waf 。 这是一个体面的系统，我用我的大部分项目是用Python编写的，源自Scons，Make和其他类似的系统。

从你提到的，我已经试过Maven – 它太严格，不扩展，是专为Java，所以我不会考虑它。 我也听到有人使用“Automake”，他们开玩笑地称之为“Autobreak”

恕我直言，寿命长的项目应该更喜欢纯粹的Make，GNU Make。 Make有几个强大的功能，通常不使用，这有助于避免样板代码（例如使用eval / call，非递归构建）。 它与其他任何构建系统兼容（例如，在我们的项目中，我们成功地将它与Ant结合，用于Java构建）。 它有一个很好的文档，并为大多数开发人员所熟悉。

根据我的经验，总是可以将项目的制造系统隔离到大多数项目makefiles包含2行的地方：目标名称和“include $ {MKSYS_HOME} /makesystem.mk”。

我努力了：

1. scons <—太慢了。
2. waf <—很好，但在我看来是过度工程 。 有时候不容易猜到要做什么。
3. cmake <—不好的语法，但相当强大，速度相当快。
4. autotools（mythbuster docs） <—只有unix。 最好的处理交叉编译。
5. tup < – 它太快而正确，令人难以置信。

你正在寻找工业实力。 我会说scons出来了，因为它太慢了恕我直言，即使它很好。 它也没有配置阶段。

waf看起来不错，但是我发现如何以正确的方式来做一些事情，特别是嵌套的项目。

autotools是非常强大的，但它是如果你想支持Windows。 交叉编译在autotools中非常强大。

CMake：我认为你应该去做这个。 它非常快，它像自动工具一样处理配置，但在Windows中工作，它为xcode，visual studio，make等生成项目。 如果你有一个多平台的项目，这是一个很好的功能，因为你可以生成所选IDE的项目。 但是我必须说，我不太喜欢这个语法。 无论如何，它处理好大项目。 如果我想要一个“工业强度”的解决方案，我会去cmake。 即使我个人讨厌一点，这是唯一可行的选择。

Tup：我认为这更多是以unix为导向的。 但我必须说，对我来说，这是最好的，而且是非常快速和简单的。 我喜欢它。 但是你需要的是cmake。

另一个要看的是Bakefile 。

它的主要优点是采用了一个相对简单的输入文件（不管怎样，XML都是简单的），并且输出了许多不同的本机构建系统文件：基于autoconf的系统（Linux，OS X命令行，BSD …）上的Makefile.in， Visual C ++解决方案和项目文件，Xcode项目，MinGW和通用Unix Makefiles等

这就是说，我不知道我会从一开始就使用这样的系统。 由于最初的目标是Linux，而其他的是“maybes”，所以考虑从automake开始，并将Bakefile（或其他）移走，直到进行移植。 在实际需要之前建造东西总是一个错误。 在这种情况下总是存在一个折衷 – 最常见的分母综合征 – 如果你今天不需要支付罚款，就把它扣除，直到你必须支付; 你可能永远不必支付。 如果你用automake去建立你的文件，这个迁移不会太痛苦。