您对非递归make有什么经验? [英] What is your experience with non-recursive make?

问题描述

几年前，我阅读了递归使被认为有害论文，并实现了这个想法在我自己的构建过程中.最近，我阅读了另一篇有关如何实现非递归make .因此，我有一些数据点指出，非递归make至少可用于一些项目.

A few years ago, I read the Recursive Make Considered Harmful paper and implemented the idea in my own build process. Recently, I read another article with ideas about how to implement non-recursive make. So I have a few data points that non-recursive make works for at least a few projects.

但是我很好奇其他人的经历.您是否尝试过非递归make?它使事情变得更好还是更糟?值得吗?

But I'm curious about the experiences of others. Have you tried non-recursive make? Did it make things better or worse? Was it worth the time?

推荐答案

我们在我工作的公司中使用非递归GNU Make系统.它基于Miller的论文，尤其是您提供的实现非递归make"链接.我们已经设法将Bergen的代码完善为一个在子目录makefile中根本没有样板的系统.总的来说，它运行良好，并且比我们以前的系统要好得多(使用GNU Automake进行递归操作).

We use a non-recursive GNU Make system in the company I work for. It's based on Miller's paper and especially the "Implementing non-recursive make" link you gave. We've managed to refine Bergen's code into a system where there's no boiler plate at all in subdirectory makefiles. By and large, it works fine, and is much better than our previous system (a recursive thing done with GNU Automake).

我们支持所有主要"操作系统(商业上):AIX，HP-UX，Linux，OS X，Solaris，Windows，甚至是AS/400大型机.我们为所有这些系统编译相同的代码，并将平台相关的部分隔离到库中.

We support all the "major" operating systems out there (commercially): AIX, HP-UX, Linux, OS X, Solaris, Windows, even the AS/400 mainframe. We compile the same code for all of these systems, with the platform dependent parts isolated into libraries.

在我们的树中，大约有2000个子目录和20000个文件，其中有超过200万行C代码.我们认真考虑过使用SCons，但无法使其足够快地工作.在较慢的系统上，Python只需花几十秒就可以解析SCons文件，而GNU Make在大约一秒钟的时间内完成了相同的操作.这大约是三年前，所以从那以后情况可能已经发生了变化.请注意，我们通常将源代码保留在NFS/CIFS共享上，并在多个平台上构建相同代码.这意味着构建工具扫描源代码树中的更改会更加慢.

There's more than two million lines of C code in our tree in about 2000 subdirectories and 20000 files. We seriously considered using SCons, but just couldn't make it work fast enough. On the slower systems, Python would use a couple of dozen seconds just parsing in the SCons files where GNU Make did the same thing in about one second. This was about three years ago, so things may have changed since then. Note that we usually keep the source code on an NFS/CIFS share and build the same code on multiple platforms. This means it's even slower for the build tool to scan the source tree for changes.

我们的非递归GNU Make系统并非没有问题.以下是您可能会遇到的一些最大障碍:

Our non-recursive GNU Make system is not without problems. Here are some of biggest hurdles you can expect to run into:

• 使其易于移植，尤其是对于Windows，是一项艰巨的工作.
• 尽管GNU Make几乎是一种可用的函数式编程语言，但不适用于大型编程.特别是，没有名称空间，模块或类似的东西可帮助您将各个部分相互隔离.这可能会引起问题，尽管不如您想像的那么多.

我们旧的递归makefile系统的主要优势是:

The major wins over our old recursive makefile system are:

• 快速.检查整个树(2k目录，20k文件)大约需要两秒钟，然后确定它是最新的还是开始编译.旧的递归操作将花费一分钟以上的时间.
• 它可以正确处理依赖关系.我们的旧系统依赖于已构建的订单子目录等.就像您从阅读Miller的论文中所期望的那样，将整棵树视为单个实体确实是解决此问题的正确方法.
• 在我们投入了大量的辛苦工作之后，它可移植到我们所有受支持的系统中.太酷了.
• 抽象系统使我们可以编写非常简洁的makefile.仅定义库的典型子目录只有两行.一行给出了库的名称，另一行列出了该库所依赖的库.

• It's fast. It takes about two seconds to check the entire tree (2k directories, 20k files) and either decide it's up to date or start compiling. The old recursive thing would take more than a minute to do nothing.
• It handles dependencies correctly. Our old system relied on the order subdirectories were built etc. Just like you'd expect from reading Miller's paper, treating the whole tree as a single entity is really the right way to tackle this problem.
• It's portable to all of our supported systems, after all the hard work we've poured into it. It's pretty cool.
• The abstraction system allows us to write very concise makefiles. A typical subdirectory which defines just a library is just two lines. One line gives the name of the library and the other lists the libraries this one depends on.

关于上述列表中的最后一项.我们最终在构建系统中实现了一种宏扩展功能.子目录生成文件在变量(例如PROGRAMS，SUBDIRS，LIBS)中列出程序，子目录，库和其他常见内容.然后，将每个扩展为真实的" GNU Make规则.这使我们避免了很多名称空间问题.例如，在我们的系统中，最好有多个具有相同名称的源文件，在那里没有问题.

Regarding the last item in the above list. We ended up implementing a sort of macro expansion facility within the build system. Subdirectory makefiles list programs, subdirectories, libraries, and other common things in variables like PROGRAMS, SUBDIRS, LIBS. Then each of these are expanded into "real" GNU Make rules. This allows us to avoid much of the namespace problems. For example, in our system it's fine to have multiple source files with the same name, no problem there.

无论如何，这最终需要大量工作.如果您可以使用SCons或类似的代码来工作，我建议您先考虑一下.

In any case, this ended up being a lot of work. If you can get SCons or similar working for your code, I'd advice you look at that first.

这篇关于您对非递归make有什么经验?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！