link: "Recursive Make Considered Harmful"

Jeroen Ruigrok/asmodai asmodai at
Tue Jan 11 01:22:22 PST 2005

-On [20050111 10:12], Andrew Hacking (ahacking at xxxxxxxxxxxxxxx) wrote:
>My thoughts on scons precisely. Powerful but cumbersome syntax for 99%
>of cases.

Plus that it seems to be a mix between what the autoconf tool and a build
tool try to do.

Now, in itself that's not bad, but you need to be weary to not let it
quickly lead to feature bloat.

>I had a look at jam, moderately interesting, but after reading the
>sybase "success story" I have reservations. see:
>As the article states, jam uses filenames as unique identifiers of
>targets across the whole source tree eg two files named foo.c in
>different directories in the source tree requires a manual tie breaker
>tag to get the one you want. This just seems lame when dealing with a
>large source base.

Mmm, ok, I hadn't tripped over that yet.  That requires some more reading
and yes, that is exceptionally lame if such is still the case.

>I was also surprised to see in jam that all variable assignment occurs
>at parsing time and cannot occur dynamically, eg as the output of a
>shell command.  This has to take away a lot of power that make provides,
>but obviously makes it easier for jam to calculate dependencies up front
>before doing anything.

Mmm, the output, are you talking about the return values or the verbatim
output a shell command can generate?

>Anyway its good to look at alternatives... and still see that make isn't
>so bad despite the limitations.

Oh, make is not bad per se, no.  I mean, I wouldn't otherwise use Simon J.
Gerraty's/NetBSD's bmake for TenDRA's build.  But I am often walking/heading
into problems area together with Eirik Nygaard that makes us go 'ewww'.

Take for example this whole mess with .USE to turn a target into a macro.
Why can't I create something like a general macro or rule and just reference
that, instead of having to abuse a target and polymorph it into a macro.
That's the problem with make, the desire to keep the backwards compatibility
to the old is both its strength and its biggest weakness.  Every new feature
seems bolted on.  And in general trying to maintain make's source code is
not a fun hobby.

Jeroen Ruigrok van der Werven <asmodai(at)> / asmodai / kita no mono
Free Tibet! |   |
Time is a twofold teacher, harsh and yet patient like no-one...

More information about the Kernel mailing list