有前途的替代品？
我已经使用make和makefiles很多年了，虽然这个概念是完善的，但是这个实现还是有一些需要的。
有没有人发现任何不错的select，以避免过度复杂的问题？
检查SCons 。 例如Doom 3和Blender使用它。
我有很多通过CMake发誓的朋友进行跨平台开发：
它是用于VTK的构build系统（其中包括），它是一个具有跨平台Python，Tcl和Java绑定的C ++库。 我认为这可能是你用这么多functionfind的最不复杂的东西。
你总是可以尝试标准的自动工具 。 如果你只在Unix上运行，并且坚持使用C / C ++，那么Automake文件很容易放在一起。 整合比较复杂，autotools远非最简单的系统。
一些GNOME项目已经迁移到waf 。
它是基于Python的，就像Scons一样，也是独立的 – 所以不要求其他开发者安装你最喜欢的构build工具，而只需将独立的构build脚本复制到你的项目中。
我build议使用Rake 。 这是我find的最简单的工具。
我用过的其他很好的工具，如果Ruby不是你的东西，
- AAP （Python）
- SCons （Python）
- Ant （Java，XML中的configuration，非常复杂）
doit是一个python工具。 它基于构build工具的概念，但更通用。
- 您可以定义一个任务/规则是如何更新的（不只是检查时间戳，不需要目标文件）
- 依赖关系可以由其他任务dynamic计算
- 任务的动作可以是python函数或shell命令
请注意受tup和redo影响的ninja构build工具（2012年9月1日）。
构build文件生成器cmake （例如用于Unix Makefiles，Visual Studio，XCode，Eclipse CDT等）也可以从版本2.8.8（2012年4月）开始生成ninja构build文件，而且afaik， ninja现在甚至是默认的构build工具由cmake 。
它应该胜过make工具（更好的依赖关系跟踪，也是并行）。
cmake是一个已经很成熟的工具。 您可以随时select构build工具，而无需修改您的configuration文件。 所以如果将来有一个更好的构build被cmake支持，你可以方便地切换到它。
请注意，对于c / c ++来说，改进编译时间有时是有限的，因为预处理器包含头文件（特别是使用只包含头文件的库文件，例如boost ＆ eigen ），希望这些文件将被模块提议所取代的c + + 11或最终在c + + 1y）。 看看这个演示文稿的细节在这个问题上。
我写了一个名为清酒的工具，试图使makefile文件很容易读写。
这取决于你想要做什么。 如果你想要的只是make-style的目标依赖和命令调用，那么Make实际上是任务更好的工具之一。 :-)耙是非常好的，但可以笨拙的一些简单的情况。 ant当然是冗长的城市，但它更好地支持构buildJava类语言（包括Scala和Groovy）。 另外，Ant可以在任何地方使用 。 这是我使用它的主要原因。 因为它在Windows上始终如一地运行，所以它实际上比Make更跨平台。
如果你想要像Java一样的库的依赖pipe理，Maven是典型的select，但是我个人更喜欢Buildr。 定制速度更快，更容易（基于Rake）。 不幸的是，它现在还不像Maven那样无处不在。
在考虑了一堆替代品之后，我仍然更喜欢make。 当你通过编译器或类似fastdep的东西来自动生成依赖关系时，就没有太多的事情要做。 特别是我不希望我的构build脚本与实现语言绑定在一起，并且当有更多可读的替代方法可用时，我不喜欢用XML写东西。 揭示通用语言的工具虽然有价值，但是另外一种解释性语言并不（afaik）。 什么是错误的使？ 可能会吸引你关于远离make的观点。
/艾伦
Ruby的make系统叫rake： http : //rake.rubyforge.org/
看起来很有希望。
总有ant： http : //ant.apache.org ，我个人觉得很可怕。 然而，这是Java开发事实上的标准。
我不确定你是否在这里问正确的问题。
你在简化了吗？ 在这种情况下，你需要找一个非常熟悉的人来创build一系列（M | m）文件来简化你的问题。
还是你想看看底层技术？ 我们是否希望强制执行一个内置于代码devise中并且在代码devise中强制实施的devise合同式架构？ 或者可能的话，语言本身，例如Ada及其规范（接口）和主体（实现）的概念？
你以后的方向肯定会影响这个问题的潜在结果吗？
基本上，只有那些真正改变了的组件的系统构build系统的新方法，与采用由devise构build的这种机制的新技术的采用相比，
对不起，这不是一个直接的答案。 只是想尝试让你评估你想要走的路。
干杯，
抢
来自RTDA的FlowTracer是另一个很好的select，我已经看到在大规模环境（数以万计的工作）商业使用： http ://www.rtda.com/flowtracer-design-flow-infrastructure-software
它有一个graphics用户界面显示依赖关系图的彩色编码框的作业和椭圆形的文件。 当作业和文件数量变多时，像FlowTracer这样的基于GUI的工具是非常重要的。
初始设置成本高于Make。 有一个学习曲线来设置你的第一个stream程使用它。 之后，它变得更快。
