C ++构建系统

Question

我将很快开始一个新的C ++项目（也可能有一些C组件），我正在寻找一个现代的，工业级的（即非beta版）构建系统。该软件将在3 - 5年内由多个开发人员创建，并将在Linux上运行（Mac OS X和Windows 可能稍后将支持）。我正在寻找具有比例如更好的可理解性，易用性和可维护性的东西。 make但仍然足够强大，可以处理复杂的项目。首选开源软件。

到目前为止，我开始关注Boost.Build，CMake，Maven和SCons并且喜欢所有这些的功能和概念，但我缺乏经验为大型项目做出决定。

Answer 1

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

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

CMake的缺点是它并没有真正附带很多内置工具，或者是一种简单的扩展方法（与MSBuild相比，MSBuild当然只是一个构建系统，而不是一个生成器） 。我们的Linux开发人员倾向于调用Unix命令行工具来执行压缩/解压缩等操作，这些工具在典型的Windows安装中不可用，而相比之下，MSBuild在社区项目中提供了数千个附加命令，因此您无需使用在命令行中，为MSBuild创建一个新的任务非常简单。我目前正在研究如何克服CMake的这些限制，因为它目前意味着我们无法完全构建在Windows上，即使代码本身可以正常构建。

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

Answer 2

未来几年......

• SCons从我所见过的人气中消失了。我根本不喜欢它。
• Waf太棒了（在我看来）。如果您正在研究SCons，请先尝试Waf。但是，并行构建始终会显示所有发生的错误...因此，您的屏幕会出现错误消息。此外，扩展可能会有点复杂。
• Boost.Build是我的最爱之一，但却拥有世界上最糟糕的文档。除此之外，它非常灵活，几乎可以做任何事情。不过，有时候它可能有点慢。
• CMake仅适用于生成忍者脚本;其他任何东西都是垃圾（1行1可执行项目的4000行makefile）
• Tup很好，但它没有任何配置。
• Autoconf仍为autocrap。

未提及的其他人：

• Kbuild有点奇怪，但看起来不错。这就是我所知道的。
• mk-configure非常适合做爱好者。
• Shake shake-language-c非常灵活，可以让您做任何事情......如果您了解Haskell并且不介意放弃VS支持。
• Jamplus喜欢在每个疯狂的编译器命令结束时推送-m32，这对于64位系统来说很糟糕。
• Tundra可能有点重复，但仍然非常快速和准确。
• Bam ......苔原更好。它在不牺牲准确性的情况下速度很快。
• Gyp（用于Google Chrome / Chromium）未被记录，但它是CMake的绝佳替代品。
如果你重视简单，那么
• Premake就很棒了，但是当看到简单的事情时，它会变得很烦人。
• Bakefile限制性非常强，但对于简单的项目非常有用。
• fbuild是我最喜欢的（和Boost.Build一起）。它的文档很少，但有很多例子和非常易读的源代码。构建脚本也很​​简短。它曾用于构建（并专为）Felix而设计。它也非常非常快，并且几乎总是非常准确，并且具有自动并行性，可以让您的屏幕充满活力。永远。我正在使用它来构建一个正则表达式JIT引擎，我感到非常非常高兴。它也很容易扩展。但是，虽然我从来没有遇到任何实际问题，但它在技术上仍处于测试阶段。

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

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

Answer 3

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

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

由于Python是跨平台的，因此SCons也没有问题。

它捆绑了大量目标：

• 检测可用的二进制文件并自动将多个扩展名映射到正确的二进制文件
• 根据操作系统检测对象/库的正确扩展名，但可以覆盖它
• 提供常用操作（在构建后延迟）的工具，如Move，Copy，Tar，你可以提供自己的python脚本并将它们挂钩
• 开箱即用，但在每个级别提供了许多自定义钩子

它非常高效，甚至提出了高级功能（比如在sqlite数据库中存储预处理文件的哈希值而不是使用时间戳），即使你最终决定了你的策略。

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

我说它效率高吗？好吧，它显然允许并行执行多个作业;）

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

我只能推荐它。

Answer 4

另一个工具是TUP。 我使用这个工具的经历非常好。 Tup

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

在将它用于两个非常复杂的项目后，我只能说一件坏事：

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

Answer 5

我有机会自己比较所有这些。首先我们使用 make 。这很难看。您必须 make 专家才能真正了解正在发生的事情。我不会再忍受痛苦了。

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

然后我将项目移至 CMake ，这绝对是我的首选工具。它的结构和语法非常易读且也有文档记录。它为几乎每个IDE生成项目，并且早期支持市场上的新IDE。然后，构建过程与IDE一样快，您只需在添加新项目或更改项目属性时返回CMake以继续使用 CMake

所以我建议 CMake

Answer 6

看看Waf。这是一个不错的系统，我用于大多数用python编写的项目，并从Scons，Make和其他系统中派生出来。

Answer 7

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

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

根据我的经验，总是可以将makeystem从项目中隔离到大多数项目makefile包含2行的程度：目标名称和“include $ {MKSYS_HOME} /makesystem.mk”。

Answer 8

我试过了：

1. scons＆lt; ---太慢了。
2. waf＆lt; ---非常好，但在我看来过度工程。有时不容易猜到该怎么做。
3. cmake＆lt; ---不是很好的语法，但非常强大且非常快。
4. autotools (mythbuster docs)＆lt; ---只有unix。最佳处理交叉编译。
5. tup＆lt; - 它是如此快速和正确，令人难以置信。

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

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

autotools非常强大，但是如果你想支持windows它就会出来。交叉编译在autotools中非常强大。

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

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

Answer 9

另一个要看的是Bakefile。

它的主要优势在于采用一个相对简单的输入文件（简单就像XML一样），并在基于autoconf的系统上运行许多不同的本机构建系统文件：Makefile.in（Linux，OS X命令行，BSD .. 。），Visual C ++解决方案和项目文件，Xcode项目，MinGW和通用Unix Makefile等。

那就是说，我不知道从一开始就会使用这样的系统。由于最初的目标是Linux而其他人是“maybes”，所以考虑从automake开始，然后将Bakefile（或其他）移开，直到你进行移植。在你真正需要之前构建东西总是错误的。在这种情况下，总会有一个权衡 - 最低共同分母综合症 - 如果你今天不必支付罚款，那就把它推迟，直到你必须支付;你可能从不必须付钱。如果你选择使用automake并合理地构建你的文件，迁移就不会太痛苦。