有希望的替代方案？ [关闭]答案

【问题标题】：Promising alternatives to make? [closed]有希望的替代方案？ [关闭]
【发布时间】：2010-09-09 04:04:48
【问题描述】：

我已经使用 make 和 makefile 很多年了，虽然这个概念是健全的，实现有一些不足之处。

有没有人找到任何不会过于复杂的好的替代方法问题？

【问题讨论】：

答案不是很大程度上取决于问题所在吗？对于我试图用它做的事情，make 太简单了。
Ruby Rake、CoffeeScript Cake、Python Scons、Java Ant/Maven、C# MSBuild、跨平台 CMake
github.com/efimovalex/gomake
makefile 很简洁，但它本身就是一种语言。我发现很难调试。对于python用户，有很多包，包括scons、luigi（适应shouldsee/luck）、snakemake、waf。 Java 的替代品有很多，但篇幅太小，无法全部写下来。
我还没有尝试过，但github.com/casey/just 听起来有点希望，“产生详细的错误消息并避免 make 的特殊性，因此调试 justfile 比调试 makefile 更容易且不那么令人惊讶”

标签： build-automation makefile

【解决方案1】：

查看SCons。例如 Doom 3 和 Blender 就利用了它。

【讨论】：

+1 for scons - 概念上非常相似，可以很容易理解，但修复了一些关于 make 更严重的问题（例如处理名称中的空格）。
SCons 只是 Python 2，在浪费了几天时间之后，使用 SCons 编译了一个用 Python 和 C++ 编写的项目的 Python 3 版本，我建议人们远离。只需使用 CMake，此时它已成为 C++ 的标准。或者，如果您想使用基于 Python 的构建系统，请使用 Meson。它运行速度很快，并且正在积极开发中，这对于 SCons 来说是不能说的。
SCons 自 2017 年 9 月（上述评论撰写后 5 个月）开始支持 Python 3，并且自 4.0 版（2020 年 7 月）起仅为 Python 3。
有趣。也许问题是基于意见的，但对答案的投票提供了问题的答案。快速浏览后，看起来他们钉了它。哦，是的，pip install scons（当然来自 venv 内部）就像一个魅力。

【解决方案2】：

我有很多朋友发誓要跨平台开发CMake：

http://www.cmake.org/

它是用于VTK（除其他外）的构建系统，它是一个具有跨平台 Python、Tcl 和 Java 绑定的 C++ 库。我认为这可能是拥有这么多功能的最简单的事情。

您总是可以尝试标准的autotools。如果您只在 Unix 上运行并且坚持使用 C/C++，则 Automake 文件很容易组合在一起。集成更加复杂，而 autotools 远非有史以来最简单的系统。

【讨论】：

请注意，CMake 仍然只是生成 makefile。因此，如果 GNU Make 实现的问题在于它不能做你想做的事情，那么 CMake 可能不会帮助你。或者自动工具，就此而言。
CMake 不只是生成 makefile。 CMake 可以针对大量不同的编译器和平台生成大量不同类型的构建文件。就个人而言，我讨厌 CMake，因为配置语法绝对令人作呕。

【解决方案3】：

doit 是一个 python 工具。它基于构建工具的概念，但更通用。

您可以定义任务/规则如何保持最新（不只是检查时间戳，不需要目标文件）
依赖关系可以由其他任务动态计算
任务的动作可以是python函数或shell命令

【讨论】：

谢谢你的回答，doit 看起来是个很棒的工具

【解决方案4】：

一些 GNOME 项目已迁移到 waf。

它是基于 Python 的，与 Scons 类似，但也是独立的 - 因此无需其他开发人员安装您最喜欢的构建工具，您只需将独立的构建脚本复制到您的项目中即可。

【讨论】：

【解决方案5】：

我建议使用Rake。这是我发现的最简单的工具。

不过，如果 Ruby 不是你的菜，我用过的其他好工具是：

AAP (Python)
SCons (Python)
Ant（Java，XML 配置，相当复杂）

【讨论】：

【解决方案6】：

注意受tup 和redo 影响的ninja 构建工具（v1.8.2 Sep 2017）。

构建文件生成器cmake（例如，用于 Unix Makefiles、Visual Studio、XCode、Eclipse CDT 等）也可以从版本 2.8.8（2012 年 4 月）生成 ninja 构建文件，并且，afaik，@ 987654334@ 现在甚至是cmake 使用的默认构建工具。

它的性能应该优于make 工具（更好的依赖关系跟踪并且也是并行化的）。

cmake 是一个成熟的工具。您可以稍后随时选择构建工具，而无需修改配置文件。因此，如果将来开发出更好的构建，cmake 将支持您可以方便地切换到它。

请注意，对于 c/c++，改进编译时间有时会受到限制，因为通过预处理器包含头文件（特别是在使用仅头文件库时，例如 boost 和 eigen），希望将被提案取代modules （在 c++11 的技术评论中或最终在 c++1y 中）。查看此presentation 了解有关此问题的详细信息。

【讨论】：

值得注意的是 tup 依赖于 fuse 并且运行 fuse 内核扩展，就我而言，这表明维护者很疯狂。 redo 两年没更新了。我推荐ninja。

【解决方案7】：

我编写了一个名为 sake 的工具，它试图让编写类似于 makefile 的东西变得非常容易读写。

【讨论】：

有趣；但是你能告诉我们一些关于你为什么认为清酒更容易“读和写”的信息吗？我们不必安装项目就能看到它回答了问题。
当然！在我看来，原始问题的作者担心 Make 的实现“使问题过于复杂”的部分原因是因为 makefile 的语法晦涩难懂。 Sake 使用以 YAML 编写的文件，根据我从其他人的输入中收集到的信息，它的读写更简单。
它使用 YAML 语法这一事实应该是答案的一部分，或许还需要详细说明 YAML 与make 语法的对比。
我刚刚使用 Sake 作为构建脚本，它很棒。谢谢你写它！
清酒非常简单。

【解决方案8】：

这在某种程度上取决于您要做什么。如果 all 你想要的是 make 风格的目标依赖和命令调用，那么 Make 实际上是完成任务的更好工具之一。 :-) Rake 非常好，但对于一些简单的情况可能会很笨拙。 Ant 当然是冗长的城市，但它更好地支持构建类 Java 语言（包括 Scala 和 Groovy）。此外，Ant 无处不在。这是我使用它的主要原因。因为它在 Windows 上始终如一地工作，所以它实际上比 Make 更具跨平台性。

如果您想要对类 Java 库进行依赖管理，Maven 是典型的选择，但我个人更喜欢 Buildr。它更快更容易定制（它基于 Rake）。不幸的是，它还没有像 Maven 那样无处不在。

【讨论】：

【解决方案9】：

在考虑了一堆替代方案后，我仍然更喜欢 make。当您通过编译器或 fastdep 之类的工具自动生成依赖项时，就没有什么可做的了。特别是，我不希望我的构建脚本与实现语言绑定，并且当有更多可读的替代方案可用时，我不喜欢用 XML 编写东西。公开通用语言的工具虽然有优点，但另一种解释语言没有（afaik）。 What is Wrong with Make? 可能会吸引您关于远离 make 的观点。

/艾伦

【讨论】：

我也更喜欢Make；它是沼泽标准，随处可用，并且该项目的任何新手都有可能以前使用过它（或者至少比其他任何东西都有更好的机会）。但。我有一个为 Visual C++ 编写的大型代码库（数千个 C++ 源文件），我正试图在 Linux 上的 GCC 下构建它。 Make 似乎是构建工具的明显选择，我们编写了一个快速而简单的转换器，可以解析 vcxproj 文件并生成 Makefile。一切都很棒，直到我们在一个名称中带有空格的项目上进行了尝试。我们该怎么办？
为了记录，我最终选择了 SCons。由于我们的转换器无论如何都是用 Python 编写的，因此很容易将其转换为 SConscript。
@Tom 我们在哪里可以获得 vcxproj 文件解析器的副本？我也在 Windows 上做一个小项目，想移植到 ubuntu。
@Maverick - 抱歉，它是专有的，我不再在那里工作。恐怕重新创建它对于复杂的构建系统来说并非易事。虽然 VS 工作区文件“只是 XML”并且确定要构建哪些源文件以及应用哪些选项并不太糟糕，但您需要考虑构建配置（调试、发布）以及解决方案和单个项目可以还可以导入任意其他 msbuild 文件。我们考虑的另一个选择是使用 msbuild 来定位 GCC - 您现在可能会发现这更容易，因为从那时起 msbuild 已经成熟了很多。

【解决方案10】：

Ruby 的 make 系统称为 rake：http://rake.rubyforge.org/

看起来很有希望。

总是有蚂蚁：http://ant.apache.org，我个人觉得这很可怕。然而，它是 Java 开发的事实标准。

【讨论】：

【解决方案11】：

来自 RTDA 的 FlowTracer 是另一个不错的选择，我已经看到它在大规模环境（数以万计的工作）中商业化使用：http://www.rtda.com/flowtracer-design-flow-infrastructure-software

它有一个图形用户界面，可以显示依赖关系图，其中包含作业的颜色编码框和文件的椭圆形。当作业和文件的数量变多时，FlowTracer 等基于 GUI 的工具就非常重要了。

初始设置成本高于 Make。使用它设置您的第一个流程有一个学习曲线。之后，它会变得更快。

【讨论】：

【解决方案12】：

我不确定你在这里问的问题是否正确。

您是否追求简化版？在这种情况下，您需要让非常熟悉 make 的人创建一系列 (M|m)akefile 来简化您的问题。

或者您想了解底层技术？我们是否要强制执行内置于代码设计中并强制执行的按合同设计类型的架构？或者可能是语言本身，例如Ada 及其规范（接口）和主体（实现）的概念？

你所追求的方向肯定会影响这样一个问题的潜在结果？

基本上，仅从真正发生变化的组件构建系统的新方法与采用设计内置此类机制的新技术相比。

对不起，这不是一个直接的答案。只是想试着让你评估你想走哪条路。

干杯，

罗伯

【讨论】：

一个复杂问题的简单答案是不可能的。在问题中提供更多焦点会有所帮助。