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
