[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: [OT] fixing make
Date: Fri, 19 Sep 2003 16:56:55 -0700 (PDT)

    > 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]