link: "Recursive Make Considered Harmful"

[Antonio Vargas]

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
> >> > 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.
> 
> <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
> http://galis.org/george/ 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:


top/Makefile
---
@include fs/Makefile
@include kernel/Makefile
all: kernel
  link -o kernel fs/all.ar kernel/all.ar
---

top/fs/Makefile
---
all.ar: inodes.o superblock.o
---

top/kernel/Makefile
---
all.ar: timer.o sched.o list.o
---


resulting in-memory master makefile:
---

# pwd = top

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

top/fs/all.ar: top/fs/inodes.o top/fs/superblocks.o

# @endinclude fs/Makefile

# pwd = top

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

top/kernel/all.ar: 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

http://wind.codepixel.com/

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