首页 / 知识

关于构建自动化:有前途的替代方案吗?

2023-04-15 14:19:00

关于构建自动化:有前途的替代方案吗?

Promising alternatives to make?

我已经使用了make和makefile很多年了,尽管这个概念
听起来不错,但实现仍有一些不足。

有没有人发现任何好的替代方法,而不会使其过于复杂
问题?


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

http://www.cmake.org/

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

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


查看SCons。例如,《毁灭战士3》和《 Blender》就利用了它。


一些GNOME项目已迁移到waf。

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


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

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

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

但是,如果您不是Ruby,那么我使用过的其他好工具是:

  • AAP(Python)
  • SCons(Python)
  • Ant(Java,XML配置,非常复杂)

请注意受tupredo影响的ninja构建工具(2017年9月v1.8.2)。

自版本2.8.8(2012年4月)起,构建文件生成器cmake(例如,用于Unix Makefile,Visual Studio,XCode,Eclipse CDT等)也可以生成ninja构建文件,而afaik ninja为现在,甚至是cmake使用的默认构建工具。

它应该胜过make工具(更好的依赖性跟踪,并且也可以并行化)。

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

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


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


这取决于您要执行的操作。如果您只需要make样式的目标依赖项和命令调用,那么Make实际上是完成任务的更好工具之一。 :-) Rake非常好,但在某些简单情况下可能很笨拙。 Ant当然是冗长的城市,但是它对构建类似Java的语言(包括Scala和Groovy)提供了更好的支持。另外,Ant随处可见。这就是我使用它的主要原因。由于它在Windows上始终如一地工作,因此它实际上比Make跨平台更多。

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


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

/艾伦


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

看起来很有前途。

总有Ant:http://ant.apache.org,我个人觉得这很可怕。但是,它是Java开发的实际标准。


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

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

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


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

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

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

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

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

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

干杯,


方案发现方法系统

最新内容

相关内容

猜你喜欢