递归制造 - 朋友还是敌人？

我在我的项目中使用(GNU)Make.我目前正在为每个目录放置一个makefile,并使用SUBDIRS指定子目录.有人向我建议,这不是使用make的理想方式,即使用一个顶级make文件(或几个,使用include拆分).我过去曾尝试迁移/使用此布局,但在我看来,这是不必要的复杂.

使用递归makefile的优点/缺点是什么？

你应该记住的第一件事(只是为了消除任何误解)是我们不是在讨论单个和多个makefile.在任何情况下,将每个子目录中的makefile拆分为一个好主意.

递归makefile很糟糕主要是因为你将依赖树分割成几棵树.这可以防止正确表达make实例之间的依赖关系.这也导致依赖树的(部分)多次重新计算,这最终是一个性能问题(尽管通常不是很大).

为了正确使用单一制作方法,您需要使用一些技巧,尤其是当您拥有大量代码库时:

首先,使用GNU make(你已经这样做了,我看到了).GNU make具有许多简化功能的功能,您不必担心兼容性.

其次,使用特定于目标的变量值.例如,这将允许您为不同的目标设置不同的CFLAGS值,而不是强迫您在整个make中使用单个CFLAGS:

 main: CFLAGS=-O2
 lib: CFLAGS=-O2 -g

第三,确保在GNU make支持的完整范围内使用VPATH/vpath.

您还希望确保没有多个具有相同名称的源文件.VPATH的一个限制是它不允许您具有特定于目标的VPATH定义,因此源文件的名称必须在单个"VPATH命名空间"中共存.

可在此处找到一篇题为"递归使被认为有害"的文章:http://miller.emu.id.au/pmiller/books/rmch/？ref = DDiyet.Com.(或者在SourceForge 的Aegis项目.)

它探讨了递归makefile的问题,并推荐了单一的makefile方法.

我广泛使用递归.每个叶子节点都有自己的makefile,考虑:

$LIBS = libfoo libbar
$(LIBS):
    cd $@ && $(MAKE)

在大型系统上,没有这种结构将是一个相当大的挑战.人们谈论"递归使被认为有害"是一个准确的评估.我认为每种情况都有一点不同,我们会做出一些妥协.