Re: make: should -j affect cwd?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Wed, Jan 18, 2012 at 10:22:47AM -0500, Mouse wrote:
 > I think the reason make has turned into a
 > horror - to the extent it has, of course - is the ancillary facilities.
 > .include, .if, .for, $(VARIABLE), $(VARIABLE:this:that:theother)....  I
 > think it is no coincidence that every issue I've had with NetBSD's
 > make, all the code I've written for it, has been around these latter
 > facilities.  They are the least amenable to theoretical consideration,
 > because the problem they are solving is difficult to codify
 > theoretically - it is fundamentally a human-interface problem.

That's not entirely true. It's a language design issue, for which
there's a substantial body of established knowledge. The problem is
that make was written (and continues to get extended) without regard
to any of that knowledge.

(This is why I keep lowering the boom on the simplistic boolean values
proposals.)

 > > More important, I would say, is that macro evaluation be scrupulously
 > > regular, evaluated in a single pass.
 > 
 > That will be a semantic change, especially as it relates to .for, I
 > think.  I also am not sure macro expansion is the right model; I would
 > want to give at least some thought to making it a real language.  It
 > seems to me many of the problems with the macro-expansion layer arise
 > because it _is_ a macro-expansion layer.  But see below.

There's not that much difference between eval of a (non-broken,
non-crippled) macro system and eval of a "real language".

There's no hope of avoiding multiple eval phases; things like $< in
recipes *must* be evaluated at runtime and other variables *must* be
expanded at parse time. (Loops are less of a problem; the current
behavior is an approximation of a sane implementation and most of the
places where it diverges that appear to users as bugs.) However, it's
possible to make the two-phase evaluation principled and reasonably
sane.

And, btw, all or nearly all the recent use of :Uconstant is required
for semantic reasons to avoid problems caused by multiple eval
passes. There is probably no way to get rid of it (without moving to a
non-string intermediate representation like my plan) but we could
doubtless make it faster.

 > > (I would like to side-step the whole issue of macros by relying on
 > > m4, but I think some globbing and variable modifiers will be needed.)
 > 
 > Can m4 even do the sort of macro expansion make does?

It can't possibly do $< and similar stuff because those aren't purely
macros and require runtime integration with make. But everything else
it probably can. However, m4 is crazy and I for one would rather stay
away from it.

-- 
David A. Holland
dholland%netbsd.org@localhost