Re: [Gnu-arch-users] Re: [OT] fixing make

[Tom Lord]

    > From: Miles Bader <address@hidden>

    > Samuel Tardieu <address@hidden> writes:
    > > I like your proposal except the first point, which is not backward
    > > compatible. Or use yet another special notation such as

    > >   target<>: dependencies

    > > to note that you want the rules to be compared and recorded.

    > I don't think it's the sort of incompatibility that would bother anyone
    > -- Makefiles are very rarely changed, and since this errs on the side of
    > safety, it's probably the right thing for most cases (nothing like
    > beating your head against a `bug' that turns out to be a compilation
    > inconsistency...).


The real question is whether or not it buys anything over
re-implementing the make-graph engine directly in the extension
language.

I can believe it very well might be better to keep `make(1)' in C with
call-outs and call-ups to the extension language ("interpretive
overhead" and comperable handwaving).  Inefficiencies in a `make(1)'
implementation tend to be very noticable, even though you might think
"bah -- compilation times dominate".

Against that, there's the issue of things like namespace simplicity
(e.g. make vars vs. vars in the interpreter).

Schematically (heh!), it's the right idea though.   The "dependency
graph" idea extends far beyond the files themselves and into the
data-flow-graph that produces the rules that relate the files.
It's the right _abstraction_ and, given a clean implementation with a
little bit of conservative choices at the right layer -- and a
sub-process `make(1)' vs. a whole-new engine should just be an
implementation detail.

If you know what I mean.

-t