Recursive Make Considered Harmful
Recursive Make Considered Harmful
复制标题
递归使得被认为是有害的
DOI：
--
复制
发表时间：
2008
期刊：
影响因子：
--
通讯作者：
Peter Miller
中科院分区：
文献类型：
--
作者：
Peter Miller
对于大型UNIX项目，构建项目的传统方法是使用递归make。在某些项目中，当您只想更改一个文件时，这会导致构建时间长得无法接受。在检查过长的构建时间的来源时，很明显，许多明显不相关的问题联合收割机结合在一起产生了延迟，但分析表明，所有这些问题都有相同的根本原因。本文探讨了一些关于使用递归make的问题，并表明它们都是同一个问题的症状。UNIX社区长期以来一直将这些症状视为生活中的事实，但不需要再忍受下去了。这些问题包括递归make，它需要“永远”才能解决它们不需要做任何事情，递归make做得太多或太少，递归make对源代码中的更改过于敏感，需要不断的Makefile干预来保持它们工作。这些问题的解决方案可以通过从第一原则看make做了什么，然后分析将递归make引入到这个活动的效果来找到。分析表明，问题源于人工划分构建为单独的子集。这反过来又导致了所描述的症状。为了避免这些症状，只需要避免分离;使用单个make会话来构建整个项目，这与单个Makefile不太一样。这个结论与在UNIX上构建大型项目时积累的民间智慧背道而驰。这种民间智慧提出的一些主要反对意见进行了审查，并表明是没有根据的。实际使用的结果更令人鼓舞，常规开发性能的改进比直觉所指示的要快得多，并且没有直觉预期的模块化妥协。整个项目的使用并不像最初看起来那样难以付诸实践。米勒，P.A.（1998），Recursive Make Considered Harmful，AUUGN Journal of AUUG Inc.，19（1），pp. 14-25.
For large UNIX projects, the traditional method of building the project is to use recursive make. On some projects, this results in build times which are unacceptably large, when all you want to do is change one file. In examining the source of the overly long build times, it became evident that a number of apparently unrelated problems combine to produce the delay, but on analysis all have the same root cause. This paper explores a number of problems regarding the use of recursive make, and shows that they are all symptoms of the same problem. Symptoms that the UNIX community have long accepted as a fact of life, but which need not be endured any longer. These problems include recursive makes which take “forever” to work out that they need to do nothing, recursive makes which do too much, or too little, recursive makes which are overly sensitive to changes in the source code and require constant Makefile intervention to keep them working. The resolution of these problems can be found by looking at what make does, from first principles, and then analyzing the effects of introducing recursive make to this activity. The analysis shows that the problem stems from the artificial partitioning of the build into separate subsets. This, in turn, leads to the symptoms described. To avoid the symptoms, it is only necessary to avoid the separation; to use a single make session to build the whole project, which is not quite the same as a single Makefile. This conclusion runs counter to much accumulated folk wisdom in building large projects on UNIX. Some of the main objections raised by this folk wisdom are examined and shown to be unfounded. The results of actual use are far more encouraging, with routine development performance improvements significantly faster than intuition may indicate, and without the intuitvely expected compromise of modularity. The use of a whole project make is not as difficult to put into practice as it may at first appear. Miller, P.A. (1998), Recursive Make Considered Harmful, AUUGN Journal of AUUG Inc., 19(1), pp. 14-25.