Re: Non-recursive makefiles

[Morrison]

> On Wed, 2006-05-24 at 13:57 +0200, Ralf Wildenhues wrote:
> > [snip..]
> - Non-recursive makefiles are suitable for projects of mediocre
> complexity. For complex projects the price of flat Makefile is high  
> and
> often doesn't pay off.

Hear hear!  After spending a fair bit of time considering the non- 
recursive makefile approach for a rather complex project, I was  
almost inclined to write up a rebuttal to Peter Miller's politicized  
rant regarding recursive make.   The paper itself makes a good  
consideration of one aspect of project build management, but from my  
perspective trades one problem (that only exists due to technical  
limitations) for another (that has its  own different technical  
limitations).  Far too much time is spent dwelling on this issue when  
both approaches can work very well depending on the situation.

> [snip..]
> Yet another aspect is size/speed of files generated from
> flat-Makefile.am. Processing all-flat Makefile.am of a source tree
> containing 100s of source-files can be annoyingly slow and easily  
> reach
> the order of several minutes, even on contemporary HW.
> I don't see how an "import feature" would help.

In the case of the BRL-CAD project, we presently have a recursive  
build approach in place where there are roughly 20-30 libraries and  
about 420 binaries that are all built depending on the  
configuration.  There are about 250 directories with Makefile.am  
files in them (out of about 315 in total) that get traversed.  If you  
add up the line counts for all the separate Makefile.am files, that  
constitutes about 11250 lines right now, with considerable build  
flexibility still not implemented yet and some of the outboard  
processing delegated to external scripts.

Utilizing a non-recursive build approach very quickly became utterly  
(and very annoyingly) slow to process and was resulting in a top- 
level Makefile.am that was quickly becoming much larger than it  
seemed necessary or useful.  It of course helps to use include  
directives and keep your logic contained to the subdirs as best  
possible, but there were a variety of cases where more logic had to  
be added to the top-level to implement features that a recursive  
build effectively provide for free.  That coupled with the inability  
to go to subdirectories and the excessive uninformative prep times  
make it seem like non-recursive really doesn't buy me much at all  
given the tradeoffs.

It's not my intent to start a rant on recursive vs non-recursive,  
it's a dead horse imo, or even flame the fundamental approach.  It  
was very nice to have at the beginning, and I do use non-recursive  
for other projects where the benefit is more clear.  For BRL-CAD,  
though, it very quickly started feeling like a massive hack only to  
avoid a rather insignificant technical limitation.  If your build  
already takes a half an hour or more, nobody really cares that you  
spent 5% more or less of your build time due to 'make' especially  
when the hack itself has its own limitations once the project is  
large enough.  For myself, I can throw CPUs and careful target  
ordering at build performance concerns.  Now.. if I could just get my  
hands on a parallel configure stage...  :-)

Cheers!
Sean