Re: link: "Recursive Make Considered Harmful"

[Andrew Hacking <ahacking@xxxxxxxxxxxxxxx>]

Hi,

I read Peter Miller's paper a while back when designing a build system
and perhaps the most difficult part is the handling of multiple targets
and per target variables/flags.  If you need different
compiler/linker/tool flags (CFLAGS/LDFLAGS/etc) for different
components, the scheme presented in the paper falls apart.  You will
notice that the example given in the paper is extremely simple and can
only build a single program, albeit from fragments in different
directories. There is no treatment on how it would be possible to build
multiple libraries and programs with differing build flags, include
paths, (what if filenames are not globally unique ?) and differing
object and library linkage requirements.

It was at this point I walked away, ironically perhaps, with the opinion
of the approach presented "considered harmful". However I have since
read of a somewhat workable system here:
        http://www.xs4all.nl/~evbergen/nonrecursive-make.html
. .. but it requires GNU make and the makefile fragments end up having
too much cryptic/convoluted logic for my liking. I prefer declarative
easy to read makefiles with all of the fancy "how-to" logic hidden away
in one or more included "build-logic" makefiles.
The link above still doesn't handle separate build/object trees (for
those who like to keep their source tree pristine), and may have some
other gotchas that are not immediately evident.

-Andrew Hacking

On Tue, 2005-01-11 at 07:05, Antonio Vargas wrote: 
> On Sun, 9 Jan 2005 17:16:44 -0500, George Georgalis <george@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@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???