[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-recursive makefiles

From: Morrison
Subject: Re: Non-recursive makefiles
Date: Wed, 24 May 2006 12:49:32 -0400

On Wed, 2006-05-24 at 13:57 +0200, Ralf Wildenhues wrote:
- 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.

Yet another aspect is size/speed of files generated from Processing all-flat 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 files in them (out of about 315 in total) that get traversed. If you add up the line counts for all the separate 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 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... :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]