问题描述
几年前，我阅读了递归生成有害论文并实现了这个想法在我自己的构建过程中.最近，我读了另一篇关于如何实现非递归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 系统.它基于米勒的论文，尤其是您提供的实现非递归生成"链接.我们已经设法将 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.
我们的树中有超过 200 万行 C 代码，大约有 2000 个子目录和 20000 个文件.我们认真考虑过使用 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.
关于上面列表中的最后一项.我们最终在构建系统中实现了一种宏扩展工具.子目录 makefile 列出程序、子目录、库和其他变量(如 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 的体验如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！