link: "Recursive Make Considered Harmful"

[Andrew Hacking]

On Tue, 2005-01-11 at 19:20, Jeroen Ruigrok/asmodai wrote: 
> >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 have never used jam, so I am only going by what I have read.
Things change/evolve etc so who knows it may not be the case now....

> >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?
My interpretation of the documentation was that it is impossible to
invoke an external tool and assign the output of a command to a
variable.  This seemed a serious limitation _if_ that is the case, and
rules out interfacing source code control systems, or whatever.

> 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.
Thats the problem with evolving technology, you typically only reach a
local maximum.
It often takes a break of tradition to reach that next level, which btw.
is why I am interested in DFly.

Its interesting that this topic coming up at this point in time since I
am currently developing a brave new build/make system at my workplace.
The system I am working on needs to be multi-platform hosted, support
cross-compilation, integrate with version control systems, and break the
traditional hierarchical "ownership" directory structure so that the
code base gets opened up for all to see and share. It must also be able
to handle multiple versions of "components" and handle all of the
dependencies both forward and reverse between different versions of
components. It must also support "build profiles" akin to the system
profile concept in gentoo.  I have been looking at both BSD ports,
gentoo's portage and other build technologies for inspiration on aspects
of the problem. The scons approach seems to have a lot of power and
generalisation but the typical build fragments which end user developers
have to deal with are just too python based for my liking, and I am sure
I would end up with a revolution on my hands....

-Andrew Hacking