tech-userlevel archive

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

Re: make: should -j affect cwd?



On Thu, Jan 19, 2012 at 12:21:49AM -0500, Mouse wrote:
 > >> I think the reason make has turned into a horror - to the extent it
 > >> has, of course - is the ancillary 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.
 > 
 > It's a language-design issue - but the real problem isn't designing a
 > language to achieve certain codified goals.  It's deciding exactly what
 > the goals we want the language to achieve are, deciding what they are
 > to sufficient precision that we can apply language-design theory and
 > engineering practice.  That's why make keeps getting twoken: because
 > people keep noticing things it doesn't do the way they want, desires
 > which haven't yet (at that point) been taken into account.

That much is certainly true. The problem can, roughly, be split up
into four parts: the concrete syntax, the semantics of the macro
language, the semantics of the graph engine, and the semantics of the
logic that runs recipes.

Of these the only part that's particularly unusual from a language-
design perspective is the graph engine, and sure enough, that's where
the worst of the cruft is, because over the years people have piled on
ad hoc extensions one after another. Oh, don't want to cut and paste
rules? Let's have suffix rules. Oh, wait, suffix rules don't work if
you have files in multiple source dirs. Let's add vpath! No, that
still sucks, let's add pattern rules (see gmake). No wait, that's
insufficiently general, let's do [nothing yet].

Not that there isn't plenty of stuff done wrong in the macro language,
but it's pretty clear which parts of that are wrong and what should be
changed to make them right.

 > > However, m4 is crazy and I for one would rather stay away from it.
 > 
 > m4 is great...for a few things.  I agree it is definitely a wrong
 > answer here, quite aside from the things that would require hooks into
 > its innards to do (like $? and $>).

I'm not at all convinced it is useful for any purpose at all, TBH.

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


Home | Main Index | Thread Index | Old Index