【问题标题】:What do companies use to build their binaries?公司使用什么来构建他们的二进制文件?
【发布时间】:2011-04-18 06:44:15
【问题描述】:

现代公司使用什么来编译和链接他们的项目?

尤其是对于大型项目,makefile 似乎不够实用,无法进行扩展。据我所知,许多公司要么使用内部构建系统,要么在现有构建系统之上使用内部脚本。

大型项目使用 make 吗? 是使用纯 Ant、Maven 等还是用一些脚本包装?

【问题讨论】:

  • 如果您认为 makefile 不可扩展,那么您不知道如何使用 make。不幸的是,这意味着你占多数。这是正确使用 make 的一个很好的入门:miller.emu.id.au/pmiller/books/rmch
  • 多大是多大?上次我构建的 Linux 内核仍然使用 make。 Apache httpd 服务器也是如此。

标签: c build-process makefile build-automation


【解决方案1】:

现在很多人使用CMake,它会为各种平台自动生成makefile。不幸的是CMake 有自己的(奇怪的)内部语言,这就是为什么我个人更喜欢SCons - 任何它不能自然地做的事情都可以很容易地添加 - 毕竟它只是 Python 代码。看看list of OS projects using SCons。其中许多都是相当大且重要的多平台构建。

【讨论】:

    【解决方案2】:

    在我上一家公司,我们使用了带有用 python 编写的自定义 SCons 脚本的英特尔编译器。开发是用 C++ 进行的。我们发布的产品是巨大的可视化软件包。

    SCons:“SCons 是一种开源软件构建工具,即下一代构建工具。将 SCons 视为经典 Make 实用程序的改进的跨平台替代品具有类似于 autoconf/automake 的集成功能和 ccache 等编译器缓存。简而言之,SCons 是一种更简单、更可靠、更快速的软件构建方式。”

    【讨论】:

    • “自定义 SCons 脚本”是什么意思?
    • 正如您将有一个自定义构建文件用于您的代码一样,您是否有一个用于相同目的的自定义 SCons 脚本。
    【解决方案3】:

    我在电信 OEM 工作了 10 多年的每一个产品都使用了品牌。有些相对较小,有些则超过 1M SLOC。大部分源代码都是c,其中有大量的c++。最常用的第 3 方资源,所有供应商都将 makefile 与他们的产品一起提供。

    请记住,您用于构建产品的系统是软件。无论该构建软件是用 make、SCons 还是其他某种语言/系统编写的,您必须了解您用来编写构建产品的软件所使用的语言。如果不这样做,您可能会在产品中引入由不正确的构建系统引起的错误。

    【讨论】:

    • 是原始 make 还是有一些用于构建正确 makefile 的包装脚本?
    • 我应该说几乎我从事过的每一个产品......有几个使用 DOS 批处理文件,但我一直试图从我的记忆。
    【解决方案4】:

    makemakefile 对于 C 来说就像 antjava 一样自然

    【讨论】:

    • 如何为大型项目编写makefile?一个可扩展、可用的makefile?我见过的最接近的xs4all.nl/~evbergen/nonrecursive-make.html 仍然有问题。
    • @Alex:我参与过一个使用 make 的大型项目(一个操作系统,附带 JVM)。它在最顶层是递归的,然后每个组件都临时决定它是否足够大以至于递归 make 是否会出现问题。因此,一些组件是递归构建的,而另一些则在它们自己的根目录中构建。 JVM 是最慢的部分,尤其是因为它并排构建了多个版本。它使用了一些相当复杂的 makefile 和一个包装 make 本身的脚本。我不记得细节了,但是添加一个新目录和构建任何子树都很容易。
    • 哦,所有常见的 Java 库类都使用该操作系统的 JNI 等价物进行了优化,这就是为什么 JVM 如此之大,也是为什么它们是使用 make 和汇编程序而不是 @ 987654328@.
    • @Steve:哇,听起来真毛骨悚然。您的 makefile 是否处理跨子树依赖项?更不用说它仍然涉及使用脚本包装make。构建大型项目的行业标准方法似乎是编写自己的脚本来包装您使用的任何构建系统:-/
    • @Alex:其实并不需要 - 操作系统没有使用太多静态链接:动态加载的“工具”(快速),以及可选的完整静态链接的操作系统映像(可能是分钟)。所以有很多跨树头依赖,很容易被 make 处理,但很少有跨树依赖于需要构建的东西。主要组件在稳定的接口后面被很好地隔离。我想这使得该方法不适用于大多数 C 项目。包装器并没有从根本上改变 make,但它确实在不同的环境中运行了几次,以构建不同版本的 Java。
    【解决方案5】:

    一些大型项目(例如 Boost)避免使用 Jams 之一。

    【讨论】:

      猜你喜欢
      • 2020-04-11
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-08-03
      • 1970-01-01
      相关资源
      最近更新 更多