Re: make: should -j affect cwd?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> People who should know say the code verges on unmaintainable.

Well, to reorder things a little...

> 1.  Do you agree that the existing make soure code is irredeemable?

No.

I do, however, think that redeeming it is likely to be no less work
than writing a new implementation from scratch.

> ISTM that the problem specification should give rise both to a simple
> program and to a small library of tree-management functions.

Well...I actually think the conceptual core of make - tsort on the
dependency graph, pruning pieces of it based on mtimes, and running
commands - is the easy part.  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.

> 1.  Do you agree that the existing make soure code is irredeemable?

As mentioned above, technically no, but for most purposes I'd say it
might as well be.

> 2.  Do you agree its behavior is irregular and idiosyncratic?

In most, especially simple, cases...no.  But in the edge cases, yes, it
can get pretty byzantine and surprising.

> 3.  Do you think that inside make(1) is a pure acylic graph solver
> struggling to be free?

Not really.  tsort(1) does that job, in isolation, just fine.  Dealing
with the dependency graph is the easy part.

>> [...phase separation...]
> 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.

> (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?  Perhaps it's
just unfamiliarity with m4 speaking, but I'm not sure how to write m4
code to turn

VAR = foo
${VAR}: $(VAR).c
        cc -o $@ $>

into

foo: foo.c
        cc -o foo foo.c

> As I said when I broached the subject, it seems to me that the
> problem make addresses is amenable to a theoretical approach.

One of the problems it addresses definitely is, that being figuring out
what needs building and choosing what command blobs to run to build it.

Another of the problems is much less so, because it is much less well
defined, that being the macro expansion part.  I would in some respects
prefer to turn it into a real language, but (a) I haven't thought about
that enough to be sure it's possible and (b) even if it is I'm not sure
it's possible to do without totally breaking compatability.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B