有前途的替代品?

我已经使用make和makefiles很多年了,虽然这个概念是完善的,但是这个实现还是有一些需要的。

有没有人发现任何不错的select,以避免过度复杂的问题?

检查SCons 。 例如Doom 3和Blender使用它。

我有很多通过CMake发誓的朋友进行跨平台开发:

http://www.cmake.org/

它是用于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命令

请注意受tupredo影响的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程使用它。 之后,它变得更快。