我多年来一直在使用Make and Makefiles,尽管该概念是正确的,但该实现还有一些不足之处。

有没有人发现任何好的替代方案可以使问题过度解决?

有帮助吗?

解决方案

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

其他提示

我有很多朋友都非常信赖 CMake 来进行跨平台开发:

http://www.cmake.org/

这是用于的构建系统 VTK (除其他外),它是一个具有跨平台 Python、Tcl 和 Java 绑定的 C++ 库。我认为这可能是您能找到的具有这么多功能的最简单的东西。

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

一些 GNOME 项目已经迁移到 瓦夫.

它是基于 Python 的,就像 Scons 一样,但也是独立的——因此不需要其他开发人员安装您最喜欢的构建工具,您只需将独立构建脚本复制到您的项目中即可。

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

不过,如果您不喜欢 Ruby,我使用过的其他好工具有:

多伊特 是一个Python工具。它基于构建工具的概念,但更通用。

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

请注意 ninja 构建工具(v1.8.2 Sep 2017)受以下因素影响 tupredo.

构建文件生成器 cmake (例如。对于 Unix Makefiles、Visual Studio、XCode、Eclipse CDT...)也可以生成 ninja 自版本 2.8.8(2012 年 4 月)以来构建文件,据我所知, ninja 现在甚至是默认的构建工具 cmake.

它的表现应该优于 make 工具(更好的依赖性跟踪并且也是并行化的)。

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

请注意,对于 c/c++,改进编译时间有时会受到限制,因为通过预处理器包含标头(特别是在使用仅标头库时,例如 促进 & 本征)有望被以下提案所取代 模块 (在 c++11 的技术审查中或最终在 c++1y 中)。看看这个 推介会 有关此问题的详细信息。

我写了一个工具叫 清酒 它试图使编写类似 makefile 的东西变得非常容易阅读和编写。

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

如果您想要类似 Java 的库的依赖管理,Maven 是规范的选择,但我个人更喜欢 Buildr。它更快、更容易定制(它基于 Rake)。不幸的是,它还没有像 Maven 那样普遍。

在考虑了一堆替代方案之后,我仍然更喜欢 make。当您通过编译器或 fastdep 之类的东西自动生成依赖项时,就没有什么可做的了。特别是,我不希望我的构建脚本与实现语言绑定,并且当有更多可读的替代方案可用时,我不喜欢用 XML 编写内容。公开通用语言的工具虽然有优点,但另一种解释语言却没有(据我所知)。 Make 出了什么问题? 可能会吸引您关于摆脱 make 的观点。

/艾伦

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

看起来很有前途。

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

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

您想要简化的制作吗?在这种情况下,您需要找一个非常熟悉 make 的人来创建一系列 (M|m)akefile 来简化您的问题。

或者你想看看底层技术吗?我们是否想要强制执行一种内置于代码设计中并在代码设计中强制执行的按合同设计类型架构?或者可能是语言本身,例如Ada 及其规范(接口)和主体(实现)的概念?

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

基本上,仅从那些真正改变的组件构建系统的新方法与采用在设计中内置此类机制的新技术不同。

抱歉,这不是直接答案。只是想让你评估一下你想要走哪条路。

干杯,

RTDA 的 FlowTracer 是我见过的在大规模环境(数万个作业)中商业使用的另一个不错的选择: http://www.rtda.com/flowtracer-design-flow-infrastruct-software

它有一个 GUI,显示依赖关系图,其中带有用于作业的颜色编码框和用于文件的椭圆形。当作业和文件的数量变多时,像 FlowTracer 这样基于 GUI 的工具就非常必要了。

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top