<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
On Tue, 2011-06-14 at 09:26 -0700, Dan Nicholson wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
<TT><FONT COLOR="#3c3c3c">On the other hand, I believe non-recursive make adds to the complexity</FONT></TT><BR>
<TT><FONT COLOR="#3c3c3c">of the build rather than reducing it. With classic recursive automake,</FONT></TT><BR>
<TT><FONT COLOR="#3c3c3c">it's very easy to divide and conquer tasks into subdirectories. Since</FONT></TT><BR>
<TT><FONT COLOR="#3c3c3c">each Makefile is separate, you can tailor it specifically to what's</FONT></TT><BR>
<TT><FONT COLOR="#3c3c3c">going on in that directory (e.g. creating manpages) and you don't have</FONT></TT><BR>
<TT><FONT COLOR="#3c3c3c">to worry about variable or pathname collisions at all.</FONT></TT><BR>
<BR>
<BR>
</BLOCKQUOTE>
That's my number one motivation. So nicely put. There will be more bugs<BR>
in non-recursive makefiles. Automake is already a significant learning curve,<BR>
and there have been plenty of bugs in any makefile with unrelated target types.<BR>
There is a high turn over rate of maintainers, when there is one.<BR>
<BR>
When anyone makes a change in a non-recursive makefile, however simple it maybe,<BR>
he has to unit test the 5 other targets in the makefile, not just the one he is familiar with. <BR>
With subdirectories, there is no risk of breaking those other targets.<BR>
<BR>
This makes it possible for people with lower level of Automake skills to perform<BR>
tasks that would otherwise be too risky. These are more project management<BR>
than technical issues. We can't assume that everyone has all the skills to do<BR>
everything.<BR>
<BR>
Anyway, I ran the test before and after the patch and there is no performance gain whatsoever.
</BODY>
</HTML>