[HEADS UP] GNU make 3.82

[Matthias Andree]

Am 14.03.2011 04:45, schrieb Ade Lovett:
>
> On Mar 13, 2011, at 16:27 , Peter Jeremy wrote:
>> Having read through this thread, it is still unclear to me why it is
>> not possible to fix up the problematic ports before importing gmake
>> 3.82, removing the need for a gmake381 port.
>
> I believe Mark has offered up, on multiple occasions a wiki page from the _first_ exp run.
>
> Of course, if port "A" fails as a result of gmake (or, quite frankly, whatever), and it has dependent ports, then unti such time as the proverbial "quick hack" to unbreak it, we have absolutely no idea of the carnage further down the tree.
>
> devel/gmake381 exists for one reason, and one reason only.  To allow -exp runs to fully test what breaks, and what doesn't with a devel/gmake being 3.82.  You'll notice that it is not attached to the build (in devel/Makefile) and it is also marked IGNORE.  Using a few extra inodes in order to be able to properly test things (you should also note that USE_GMAKE=381 is merely part of an -exp patchset, and not present in the existing Mk/bsd.port.mk) is a minor cost for substantial gains when actually running said -exp runs.
>
> Could this have been handled better.  Sure, maybe.  But it would require *proactive* work within the community as opposed to the "you're doing it wrong" *reactive* mentality.  It's easy to criticize.  Much harder to do work that affects thousand of ports and, in the best case, no-one actually sees a change.

Dear colleagues,

I've been reading this discussion on and off and trying to get on top of 
the facts to make up my own mind.

Looks like people who have done the work (Ade and Mark) first didn't 
know the exact implications of non-triviality of the task, and have now 
become defensive, and Doug has become frustrated about a perceived lack 
of information -- that I have shared for a couple of days, until the 
Wiki address crossed my Inbox, possibly for the 2nd time.

I think we all agree that we have learnt a bit from how things happened, 
and people involved in the frame-work and -exp runs will probably do 
things differently the next time around.

You all are in what I'd call a violent agreement, and it's naturally 
easier to criticise with hindsight.

However, please let's quit the defending now and get productive again, 
and please share information about possible framework breakage sooner.

As much as we would have liked the GNU make maintainers to call this 
"pick up the shards" release 4.00, this hasn't happened, and we've got 
to deal with it, and work is underway to achieve just that.

What I've understood is that the first -exp run didn't get us the whole 
picture and thus the gmake381 hack was added to get an overview and cut 
the dependency tree short -- but nonetheless it is useful to start the 
job of fixing gmake 3.82 incompatibilities while 2nd, 3rd, 4th -exp 
passes proceed.  I've also seen that there are volunteers, such as 
maintainers and unaffiliated contributors who are always willing to lend 
a hand, have been trying to sort things out for gmake 3.82.

Of course being more transparent and open with information can cause 
anxiety, but if more people take interest in an issue, things get 
understood and fixed sooner.  The only remaining question is whether a 
policy needs to be established to do such -exp things openly in general, 
or if it was just a lack of proactive communication as a one-time event 
that will not happen again anyways.  And I'd rather not overengineer.

Anyways, I see *chance there* for the -exp and autotools and gmake 
janitors to share a bit of their task "get gmake3.82 in ports to fly" 
workload on more shoulders.

Best

-- 
Matthias Andree