link: "Recursive Make Considered Harmful"

Antonio Vargas windenntw at
Mon Jan 10 13:08:12 PST 2005

On Sun, 9 Jan 2005 17:16:44 -0500, George Georgalis <george at xxxxxxxxx> wrote:
> HI -
> 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
> >> >
> >> > 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.
> <snip>
> >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
> Makefiles... YMMV
> 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
> --
> George Georgalis, systems architect, administrator Linux BSD IXOYE
> cell:646-331-2027 mailto:george at xxxxxxxxx

I can but wonder if ths simple scheme would work:

1. We make some way to do #include on a makefile

2. When we #include a makefile, we alter it's target and dependencies
so that they get the proper path

3. At the end of reading the top-tree makefile memory has a master
makefile and we don't have to change any of the inner ones.

Example just in case I din't explain:

@include fs/Makefile
@include kernel/Makefile
all: kernel
  link -o kernel fs/ kernel/

--- inodes.o superblock.o

--- timer.o sched.o list.o

resulting in-memory master makefile:

# pwd = top

# @include fs/Makefile
# pwd == top/fs
# original: inodes.o superblock.o
# replacing: $PWD/ $PWD/inodes.o $PWD/superblocks.o

top/fs/ top/fs/inodes.o top/fs/superblocks.o

# @endinclude fs/Makefile

# pwd = top

# @include kernel/Makefile
# pwd == top/kernel
# original: timer.o sched.o list.o
# replacing: $PWD/ $PWD/timer.o $PWD/sched.o $PWD/list.o

top/kernel/ top/kernel/timer.o top/kernel/sched.o top/kernel/list.o

# @endinclude kernel/Makefile

#pwd = top

I'm not that big a make hacker, but it can't be that bad internally...
did I miss something totally obvious???

Greetz, Antonio Vargas aka winden of network

Las cosas no son lo que parecen, excepto cuando parecen lo que si son.

More information about the Kernel mailing list