Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Frank Heckenbach]

Edward Welbourne wrote:

> >> All but one of those I've looked into is manifestly less powerful than
> >> make (and I'm still waiting for my former colleagues to get the
> >> exception released to open source).
> 
> > I have no illusions that there aren't very serious issues with make and
> > I have nothing bad to say about people who choose a different tool, or
> > even write a different tool.  Make is weighed down by standardization
> > and history, so starting over from scratch has a lot of appeal.
> 
> Indeed - and that's sorta the story behind my one exception - but I've
> seen *many* claims of "this is *hugely* better than make" that were
> grounded only in a profound ignorance of what make (or, at the very
> least, GNU make, which was usually what they actually meant) could do.

Me too. It often appears to me they fixed one (real or perceived)
problem they had with make, and neglected everything else, so the
result is a specialized system suited for their own needs, but
hardly useful for different kinds of projects. Yet they're often
advertised as general make replacements.

After seeing a number of them, and when faced with the decision what
to use myself, I still came to the conclusion that using make was
less painful, even though, like Paul says, it has some issues
(*cough* tab as a significant character).

That's even though I kind of despise the autotools with their
autofoo upon autobar and generated files generated from other
generated files, and spamming every source directory with lots of
templates, generated files, and copies of most of the autotools
themselves. I think the design is fundamentally flawed, they should
have been made a library (of scripts, Makefiles, etc.) that other
packages can use rather than forcing themselves into their
distributions. Maybe it was a reasonable decision in the 1980s when
GNU programs were usually built on proprietary Unix systems, whereas
today they're often built on existing GNU-based distributions
(Linux, Cygwin, ...) where an autotools library could have just been
included, and for other systems, installing autotools would be an
extra one-time job like installing a required source library.

Anyway, it's getting off-topic, but my point is, everything I needed
that automake could possibly have done for me, I was actually able
to do with make features. Sure, I had to require GNU make (which is
no problem since it's quite portable itself), but as they say, every
problem can be solved with another layer of indirection, and since
(GNU) make allows that (in variable names or with "define" or
"include", e.g. for things like "Generating Prerequisites
Automatically", which I did based on the way as described in the
manual), so among other GNU make features, I could do all I need,
without needing a make replacement, or layers of autotools. That
makes GNU make still a valuable tool for me (even though without
historical ballast it could have been even better, but the same goes
for C, C++ and much else). So far I've had only two major wishes
with regard to my build process:

- "Correct" parallel builds, especially WRT output messages. This is
  now solved with output-sync (which brings this message back
  on-topic for a short moment :-).

- That my Makefiles be readable. But I guess you can't have
  everything. ;-) At least I've put all the dirty stuff in one
  generic Makefile which is included from the individual Makefile
  which then are quite short and mostly trivial, usually just a
  bunch of variable assignments and a few straightforward local
  rules. So having one write-only Makefile in my codebase is just
  acceptable and certainly better than the alternatives I've
  considered.

> Eventually I had a (bright young) colleague who was faced with a mess of
> make-files (that I'd made less of a mess, so folk asked me about,
> despite my reservations about how it was after my efforts) and tried
> earnestly to make them better (as opposed to *less horrendous* - which
> was my modest goal) a few times, then finally ended on the "we need
> something better than make" road (and had the generosity to still ask me
> for advice on that road) where he would have made the same mistakes I'd
> seen several times over, but I told him about them; and he's done
> something I want you all to see, mainly to get a less partial (he's my
> friend and I helped him design it, so I'm very very biassed) view of the
> tool he came up with.  It *may* be better (*I* think it is, so does he,
> and he's a smart lad)

That sounds interesting. While we're on the topic I wonder, does it
support parallel builds (I hope so, since for me, they're essential
today and will only get more important, seeing the development of
CPU frequencies and number of cores), and if so, how does it handle
output from parallel jobs?