DragonFly kernel List (threaded) for 2005-01
Re: link: "Recursive Make Considered Harmful"
On Sun, Jan 09, 2005 at 04:49:34PM +0100, Simon 'corecode' Schubert wrote:
>On Sunday, 9. January 2005 16:39, Joerg Sonnenberger wrote:
>> > I've been mulling over the pdf file linked here
>> > http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
>> > Recursive Make Considered Harmful, Peter Miller
>> This paper outlines a lot of problems of gmake and the use of gmake.
>> It doesn't apply to BSD make so such, because most of our tree uses
>> very small Makefiles which can't be merged into a simple master
>> Makefile without a lot of hassle, possible even reducing speed for
>> certain usage patterns.
I'm not sure I understand that. Very small targets can fit in a global
Makefile, with addition of path (and still do their one thing very
well); the trees don't have to change... of course you do have to start
from the top and work down, to migrate.
The paper says there's nothing wrong with "make"; it's addressing
recursive build schemes.
>i think our build system is nice and polished, but sucks wrt speed. it
>runs down the tree multiple times. that's just evil. here, figuring out
>that nothing has to be done (make quickworld after make quickworld)
>needs several minutes. with a complete dependancy graph, this could be
>figured out in seconds (see kernel make).
I'm not really qualified to say one way is best, and with my current
project, modular and monolithic approaches helped in their own ways.
I started with a modules, mostly 2 but as many as 3 levels deep. That
helped a lot with organizing and partitioning the tasks for the first
run through, but when I needed to make major changes, following that
was not as easy. About that time I got the link and I've been pushing
the targets back into the global Makefile. So, nevermind the build
time, it seems easier develop modularly but maintain non-recursive
Does recursive make provide any benefits other than human organization?
My feeling is to continue to develop (and I'm scripting, not coding C)
modular (recursive) Makefiles but with the plan of pushing them back to
a global Makefile at some point, which amounts to not assuming $PWD but
defining ./ with a macro.
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@xxxxxxxxx