代码之家  ›  专栏  ›  技术社区  ›  mike511

有希望的替代方案?[闭门]

  •  66
  • mike511  · 技术社区  · 16 年前

    我已经使用make和makefile很多年了,虽然这个概念 如果这是合理的,那么实现就有一些需要改进的地方。

    有没有人找到任何好的替代品,使之不会过于复杂

    12 回复  |  直到 15 年前
        1
  •  31
  •   WaldWolf    16 年前

    退房 SCons . 例如,《末日3》和《搅拌机》就利用了它。

        2
  •  27
  •   Todd Gamblin    16 年前

    http://www.cmake.org/

    这是用于 VTK

    你可以试试标准 autotools . 如果您只在Unix上运行,并且坚持使用C/C++,那么自动生成文件非常容易组合在一起。集成更为复杂,autotools远不是有史以来最简单的系统。

        3
  •  21
  •   schettino72    10 年前

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

    • 您可以定义任务/规则是如何更新的(不仅仅是检查时间戳,不需要目标文件)
    • 任务的操作可以是python函数或shell命令
        4
  •  16
  •   Eric Talevich    16 年前

    一些GNOME项目已经迁移到 waf .

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

        5
  •  15
  •   Stéphane    7 年前

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

    不过,如果你不喜欢Ruby,我还使用过其他好工具:

        6
  •  7
  •   tutejszy    7 年前

    注意 ninja 受以下因素影响的构建工具(2017年9月1.8.2版) tup redo

    构建文件生成器 cmake (例如,对于Unix Makefiles、Visual Studio、XCode、Eclipse CDT等)也可以生成 忍者 自版本2.8.8(2012年4月)起生成文件,并且, 忍者 现在甚至是 克马克 .

    make 工具(更好的依赖项跟踪和并行化)。

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

    boost eigen )希望能被 modules (在c++11的技术回顾中,或最终在c++1y中)。看看这个 presentation 有关此问题的详细信息。

        7
  •  5
  •   tonyfischetti    11 年前

    sake 这使得编写类似makefile的东西非常容易读写。

        8
  •  4
  •   Daniel Spiewak    16 年前

    这取决于你想做什么。如果 全部的 处处 . 这是我使用它的主要原因。因为它在Windows上工作一致,所以它实际上比Make更具跨平台性。

    如果您想对类似Java的库进行依赖性管理,Maven是一个典型的选择,但我个人更喜欢Buildr。它更快,更容易定制(它基于Rake)。不幸的是,它还没有像Maven那样无处不在。

        9
  •  3
  •   Tom    10 年前

    在考虑了一系列的替代方案后,我仍然更喜欢make。当您通过编译器或类似fastdep的东西自动生成依赖项时,就没有多少事情可做了。特别是,我不希望我的构建脚本与实现语言绑定,并且我不喜欢在有更可读的替代方案时用XML编写东西。尽管公开通用语言的工具有其优点,但另一种解释语言却没有(afaik)。 What is Wrong with Make? 可能会吸引你关于离开make的观点。

        10
  •  2
  •   davetron5000    16 年前

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

    看起来很有希望。

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

        11
  •  1
  •   bu11d0zer    13 年前

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

    它有一个GUI,其中显示了依赖关系图,其中包含作业的彩色编码框和文件的椭圆形。当作业和文件的数量越来越多时,基于GUI的工具(如FlowTracer)非常重要。

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

        12
  •  0
  •   Rob Wells    16 年前

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

    你想要一个简单的品牌吗?在这种情况下,您需要让非常熟悉make的人创建一系列(M | M)文件来简化您的问题。

    或者你想看看底层的技术?我们是否希望实施一个内置于代码设计中并在代码设计中实施的契约式设计体系结构?或者可能是语言本身,例如Ada及其规范(接口)和主体(实现)的概念?

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

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

    对不起,这不是直接的回答。只是想让你评估一下你想走哪条路。

    抢劫