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

[Edward Welbourne]

> No, that wouldn't work.  It's not the individual command (between
> simicolons) that's too long, the problem is that make can't invoke the
> shell itself because the command line + environment is too large.  The
> only way to work around this limitation is to avoid invoking a single
> command that's too long.

Ah - OK - kudos belongs to Joakim Bengtsson, FWIW; it was his hack, I
was the one too lazy to work out what the actual problem was.

>> 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.

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) but I'm *very* skeptical of such evaluations from
those who have been implicated in developing tools that are allegedly
better than make, becauase all the ones I *haven't* had a personal stake
in have *very* *very* *very* obviously sucked compared to GNU make (even
if I restrict to 3.80, as - I think I mentioned them before - some
project managers forced me to do).

Speaking of which, Paul: kudos for what you've done.  Maintenance is a
(usually) thankless business torn by contradictory demands.  Whether the
flow-er is or not better than make, gmake is *the* tool I reach for when
I need a build system (and don't yet have flower available, outside my
old-old job).  I've been doing that for as long as I have actually
understood how make works (about a decade and a half) and I've
*repeatedly* seen projects waste developer-*years* on Gettting It Wrong,
usually because they haven't learned to use the tool right.  *I* learned
how make worked by inheriting one of those "replace make with something
better" projects.  The seminal "recursive make considered harmful" paper
(google it) isn't entirely right but the lessons it teaches fix nearly
everything that is percieved as being "wrong" with make - nearly all of
which is "the make-file maintainer didn't do the home-work" (or, well,
actually - usually there was no-one that actually took on the
responsibility of maintaining the make-files, so they got bodged around
by a bunch of different developers with different hammer-sets, who thus
viewed different things as nails in different ways, with horrendous
results).

Lamentable though it is: many, that don't have command over the tool
they get to use, have - thanks to GNU make - an industry (de facto)
standard that everything else has to live up to and (even taking into
account sporadic paranoid project managers who won't allow upgrades on
build machines) it is *way* *way* better than the other versions of make
that I've had occasion to be lumbered with working with.  These days I'm
senior enough to Lay Down The Law on project managers and tell them that
the version of make doesn't affect the binaries that the (always always
always GNU, even if antiquated because that's the target system)
compile-and-link tool-chain creates - so there *is no reason at all* to
object to upgrading the version of (GNU) make on build machines - but
I've had to fight that war several times before I learned how to do the
(dumb stupid) *rhetoric* needed to win it.  Less experienced (in the
horrors of politics) developers have to live with stupidity (within
which, 20th century versions of GNU make are the gentle alternatives)
and you are giving them a credible path out of that nightmare.
Thank you.

I'll just say that again: THANK YOU.

        Eddy.
-- 
/me abstains from banging head on wall because the architects of this
building probably didn't take into account the possibility of folk with
5% and more neanderthal ancestry.  I have a very solid head - which has
saved my life at leeast once, where the opposition was a granite slab,
in about a two metre (unintended) head-dive.  The poor innocent (brick)
walls don't deserve to be taught about that.