有希望的替代品吗？[关闭]

80

我使用make和makefile已经很多年了，尽管这个概念很合理，但是实现还是有待改进的。

有没有人找到任何好的替代方法来解决这个问题呢？

build-automation  makefile 
— mike511
source
答案是否会严重取决于问题所在？对于我尝试使用它进行的操作，make太简单了。
— reinierpost，2012年
Ruby Rake，CoffeeScript Cake，Python Scons，Java Ant / Maven，C＃MSBuild，跨平台CMake
— FilBot3
— Alex Efimov
makefile很简洁，但是语言本身。我发现很难调试。对于python用户，有许多软件包，包括scons，luigi（适应于shouldsee/luck）snakemake，，waf。Java替代品很多，但是这个空间太小，无法全部写下来。
— 应该在
我还没有尝试过，但是github.com/casey/just听起来很有希望，“产生详细的错误消息并避免make的特质，因此调试justfile比调试makefile更加容易且不令人惊讶”
— Jan-Philip Gehrcke博士

Answers:

30

签出SCons。例如，《毁灭战士3》和《 Blender》就利用了它。

— 沃尔德·沃尔夫
source
scons +1-概念上足够相似，可以很容易地绕开，但可以修复一些关于make的更坏的问题（例如处理名称中的空格）。
— 汤姆
5
SCons仅适用于Python 2，在浪费了几天的时间后，使用SCons编译用Python和C ++编写的项目的Python 3版本，我建议人们不要使用。只需使用CMake，目前它已成为C ++的标准。或者，如果您想使用基于Python的构建系统，请使用Meson。它运行速度很快，并且正在积极开发中，这对于SCons而言可谓不尽人意。
— ostrokach
SCons自2017年9月（写以上注释后的5个月）以来一直支持Python 3，并且仅自版本4.0（2020年7月）以来才支持Python 3 。
— Michael Plates
27

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

http://www.cmake.org/

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

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

— 托德·甘布林
source
9
请注意，CMake仍仅生成makefile。因此，如果GNU Make的实现问题在于它无法执行您想要的操作，则CMake可能不会为您提供帮助。还是自动工具。
— 汤姆（Tom）
14
CMake不仅会生成makefile。CMake可以针对大量不同的编译器和平台生成大量不同种类的构建文件。我个人讨厌CMake，因为配置语法绝对令人作呕。
— Taywee '16
18

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

  • 您可以定义任务/规则的最新状态（不仅检查时间戳，不需要目标文件）
  • 依赖关系可以由其他任务动态计算
  • 任务的动作可以是python函数或shell命令
— schettino72
source
1
谢谢您这个答案，doit看起来像一个了不起的工具
— Bedros 18-2-22
16

一些GNOME项目已迁移到waf。

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

— 埃里克·塔列维奇（Eric Talevich）
source
13

我建议使用Rake。这是我找到的最简单的工具。

但是，如果您不是Ruby，那么我使用的其他好工具是：

  • AAP（Python）
  • SCons（Python）
  • Ant（Java，XML配置，非常复杂）
— 克林顿·德赖斯巴赫
source
7

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

自版本2.8.8（2012年4月）起，构建文件生成器cmake（例如，用于Unix Makefile，Visual Studio，XCode，Eclipse CDT等）也可以生成ninja构建文件，并且afaikninja现已成为供以下人员使用的默认构建工具：cmake。

它应该胜过该make工具（更好的依赖跟踪，也可以并行化）。

cmake是已经建立的工具。您以后总是可以选择构建工具，而无需修改配置文件。因此，如果将来开发出更好的构建，而cmake您将获得支持，则可以方便地切换到该构建。

请注意，对于c / c ++，由于通过预处理器包含的头文件（特别是在使用仅头文件的库，例如boost＆eigen时）有时会限制编译时间，因此有望被模块建议所取代（在技术评论中） c ++ 11或最终在c ++ 1y中）。请查看此演示文稿以获取有关此问题的详细信息。

— 霍奇克
source
3
尤其tup取决于fuse并运行保险丝内核扩展，就我而言，这表明维护人员很疯狂。redo两年未更新。我建议ninja。
— mxcl 2013年
5

我写了一个叫做缘故的工具，试图使编写类似makefile的东西非常容易读写。

— 托尼菲舍蒂
source
有趣; 但是您能否提供一些有关为什么您认为清酒更容易“读写”的信息？我们不必安装项目即可看到它可以回答问题。
— Dour High Arch
当然！在我看来，最初问题的作者之所以担心Make的实现“使问题过于复杂”，部分原因在于makefiles的语法晦涩难懂。Sake使用以YAML编写的文件，并且根据我从其他人的输入中收集的信息，该文件更易于读写。
— tonyfischetti
它使用YAML语法的事实应该是答案的一部分，也许需要详细说明YAML与make语法的对比。
— 亚伦·诺夫斯特鲁普
我只是使用Sake作为构建脚本，它很棒。谢谢你写！
— nooblar 2015年
清酒非常简单。
— 丹
4

这取决于您要执行的操作。如果所有你想要的是补充型靶依赖和命令调用，然后做实际上是任务的更好的工具之一。:-) Rake非常好，但在某些简单情况下可能很笨拙。Ant当然是冗长的城市，但是它对构建类似Java的语言（包括Scala和Groovy）提供了更好的支持。另外，Ant随处可见。这就是我使用它的主要原因。由于它在Windows上始终如一地工作，因此它实际上比Make跨平台更多。

如果您希望对类似Java的库进行依赖管理，则可以选择Maven，但我个人更喜欢Buildr。更快，更容易自定义（基于Rake）。不幸的是，它还没有Maven普及。

— 丹尼尔·斯皮瓦克（Daniel Spiewak）
source
2

在考虑了很多替代方案之后，我仍然更喜欢make。当您通过编译器或类似fastdep之类的方法自动生成依赖项时，没有太多要做。特别是，我不希望将构建脚本与实现语言联系在一起，并且当有更多可读的替代方法时，我不喜欢用XML编写内容。虽然可以使用公开通用语言的工具，但不能使用另一种解释语言（afaik）。 Make有什么问题？可能会吸引您关于脱离品牌的观点。

/艾伦

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

我已经看到RTDA的FlowTracer是另一个很好的选择，我已经看到它在大规模环境（成千上万的工作）中用于商业用途：http ://www.rtda.com/flowtracer-design-flow-infrastructure-software

它具有一个GUI，该GUI显示依赖项图，其中带有用于作业的颜色编码框和用于文件的椭圆形框。当作业和文件数量增加时，像FlowTracer这样的基于GUI的工具就非常重要。

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

— bu11d0zer
source
0

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

您是否经过简化制作？在这种情况下，您需要让一个非常熟悉make的人创建一系列（M | m）akefile，以简化您的问题。

还是您想研究基础技术？我们是否要强制执行代码设计中内置和强制执行的按合同设计类型的体系结构？或者可能是语言本身，例如Ada及其规范（接口）和主体（实现）的概念？

您所追求的方向肯定会影响该问题的潜在结果？

基本上，仅从真正发生变化的组件构建系统的新方法，而不是采用通过设计内置这种机制的新技术。

抱歉，这不是直接答案。只是想尝试让您评估您想朝哪个方向走。

干杯，

抢

— 罗伯·威尔斯
source
一个简单的问题的简单答案是不可能的。在这个问题上提供更多的关注将有所帮助。
— 罗布·威尔斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.