多年来，我一直在使用 make 和 makefile，虽然这个概念是合理的，但实现仍有一些不足之处。
有没有人找到任何好的替代方案来使问题不会过度复杂化？
mike511
问问题
52172 次
12 回答
31
查看SCons。例如 Doom 3 和 Blender 就使用了它。
于 2008-09-15T20:51:09.727 回答
21
doit是一个 Python 工具。它基于构建工具的概念，但更通用。
- 您可以定义任务/规则如何保持最新（不只是检查时间戳，不需要目标文件）
- 依赖关系可以由其他任务动态计算
- 任务的动作可以是 python 函数或 shell 命令
于 2012-03-30T03:51:48.720 回答
16
一些 GNOME 项目已经迁移到waf。
它是基于 Python 的，就像 Scons 一样，但也是独立的——所以不需要其他开发人员安装您最喜欢的构建工具，您只需将独立的构建脚本复制到您的项目中即可。
于 2008-09-15T20:59:03.887 回答
7
请注意受和ninja影响的构建工具（v1.8.2 2017 年 9 月）。tupredo
自版本 2.8.8（2012 年 4 月）以来，构建文件生成器cmake（例如，用于 Unix Makefiles、Visual Studio、XCode、Eclipse CDT 等）也可以生成ninja构建文件，而且，afaikninja现在甚至是cmake.
它应该优于该make工具（更好的依赖跟踪并且也是并行化的）。
cmake是一个已经很成熟的工具。您始终可以稍后选择构建工具，而无需修改配置文件。因此，如果将来开发出更好的构建，cmake您可以方便地切换到它。
请注意，对于 c/c++，改进编译时间有时会受到限制，因为预处理器中包含的头文件（特别是在使用仅包含头文件的库时，例如boost和eigen）希望将被模块的提议所取代（在技术审查中c++11 或最终在 c++1y 中）。查看此演示文稿以了解有关此问题的详细信息。
于 2013-03-21T14:47:21.407 回答
5
我编写了一个名为sake的工具，它试图让编写类似makefile 的东西变得非常容易读写。
于 2014-01-08T19:13:21.117 回答
4
这有点取决于你想要做什么。如果你想要的只是 make 风格的目标依赖和命令调用，那么 Make 实际上是完成任务的更好工具之一。:-) Rake 非常好，但对于一些简单的情况可能会很笨拙。Ant 当然是冗长的城市，但它更好地支持构建类 Java 语言（包括 Scala 和 Groovy）。此外，Ant随处可用。这是我使用它的主要原因。因为它在 Windows 上始终如一地工作，所以它实际上比 Make 更具跨平台性。
如果你想对类 Java 库进行依赖管理，Maven 是典型的选择，但我个人更喜欢 Buildr。它更快更容易定制（它基于 Rake）。不幸的是，它还没有像 Maven 那样无处不在。
于 2008-09-15T20:56:10.523 回答
3
在考虑了一堆替代品之后，我仍然更喜欢 make 。当您通过编译器或 fastdep 之类的工具自动生成依赖项时，就没有什么可做的了。特别是，我不希望我的构建脚本与实现语言绑定，并且当有更多可读的替代方案可用时，我不喜欢用 XML 编写东西。公开通用语言的工具虽然有优点，但另一种解释语言没有（afaik）。 Make有什么问题？可能会吸引您关于远离 make 的观点。
/艾伦
于 2008-09-15T21:25:53.603 回答
2
Ruby 的 make 系统称为 rake：http ://rake.rubyforge.org/
看起来很有希望。
总是有 Ant：http ://ant.apache.org ，我个人觉得这很可怕。然而，它是 Java 开发的事实上的标准。
于 2008-09-15T20:50:52.223 回答
1
RTDA 的 FlowTracer 是另一个不错的选择，我在大型环境（数以万计的工作）中看到商业用途：http ://www.rtda.com/flowtracer-design-flow-infrastructure-software
它有一个 GUI，它显示了依赖关系图，其中包含用于作业的颜色编码框和用于文件的椭圆形。当作业和文件的数量变多时，FlowTracer 等基于 GUI 的工具非常重要。
初始设置成本高于 Make。使用它设置您的第一个流程有一个学习曲线。之后，它变得更快。
于 2012-05-29T23:05:08.190 回答
0
我不确定你在这里问的问题是否正确。
你追求简化的制作吗？在这种情况下，您需要让非常熟悉 make 的人创建一系列 (M|m)akefile 来简化您的问题。
或者你想看看底层技术？我们是否要强制执行内置于代码设计中并强制执行的按合同设计类型的架构？或者可能是语言本身，例如 Ada 及其规范（接口）和主体（实现）的概念？
你所追求的方向肯定会影响这样一个问题的潜在结果？
基本上，仅从那些真正改变的组件构建系统的新方法与采用具有设计内置此类机制的新技术的采用。
对不起，这不是一个直接的答案。只是想试着让你评估你想走哪条路。
干杯，
抢
于 2008-09-15T21:02:42.397 回答