Re: [cygwin] cwrapper emits wrapper script

[libtool]

On Wed, 25 Apr 2007 23:01:10 +0200, "Ralf Wildenhues"
> FWIW, this isn't going to change a lot for me.  If I have doubts that
> changes are free of regressions, then there is work to be done.

agreed.

> It's
> not helpful if GCC developers have to sort out those regressions.
> Conversely, if GCC retains the policy of updating its Libtool files at
> most once every decade, then we can't help them, no matter what bug
> we're talking about.

Right.  The problem was that they had modified their local version of
libtool-1.4.x, and were therefore nervous about upgrading and losing
those "fixes".  Plus, they had to update autoconf from 2.13 and automake
from 1.[4p5|7|8,depending] throughout, first -- and that took a while. 
A looonnnng while.

However, similar problems should be avoided in the future, because from
what I understand, the new rules are: either use an official, unpatched,
released version of external tools (like libtool), or use an unpatched
version taken directly from the external development tree.  The only
problem I see is if libtool-HEAD-after-2.0 (say, nearing the /next/
major release) begins requiring ac-2.61/am-1.10 (or even newer).  Then
gcc would be stuck with their unpatched snapshot of libtool-HEAD from
before that new libtool requirement, until they updated ac/am.

I suspect they will make more of an effort to keep up with current
autotools, plus I think any future ac/am updates will be much less, err,
issue-prone than the ac-2.13/ac-2.5x transition was.
 
> Primary aim is to release Libtool 2.  Effectively you are suggesting
> that Cygwin's "transparent_exe" feature, its argz bug, and the MinGW
> breakage of cwrapper be considered release blockers.

The latter two, yes: see below.  The first one: no.  Only, if you ARE
going to accept it before 2.0, then I'd prefer to get that done before
the upcoming gcc import, rather than miss it by a few days.  If you're
NOT going to accept it pre-2.0, or if it takes a month to stabilize and
we miss the gcc "deadline" by _weeks_, then no problem.

> Which I personally don't have a problem with, especially if you're the
> one doing all the hard work and effectively end up doing the maintenance
> as well.  ;-)  But I think that should be noted.  And the next time you
> cry about the release process being ever slower, I'll remind you of this
> point.  ;-)

I call shenanigans.  The argz stuff notwithstanding, the very idea of
fixing the "transparent_exe" issue &etc was rejected by me a year ago as
being too destabilizing for 2.0(.0), which was due Real Soon Then.

http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html
"Sadly, it's too late for any such major change to get into
libtool-2.0[ed: 2.0.0 initial release] because libtool is effectively in
code-slush right now. But, if *somebody* implements this fix I'll put it
in cygwin's dist of libtool-2.0 and push for it to go into
libtool-2.0.x.[ed: x > 0]"

It was rejected AGAIN by me two weeks ago as being too destabilizing for
2.0:
http://cygwin.com/ml/cygwin/2007-04/msg00543.html
"Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the desired fixes will have to wait until
after 2.0."

It was you who said in response, last week:
http://cygwin.com/ml/cygwin/2007-04/msg00549.html
"... I'd prefer to see such a patch before deciding when it's good to
put it in."

So, I began feeding those patches.  I was surprised when you accepted in
principle -- and then actually committed -- the first "use functions to
emit wrapper code" patch without even seeing the others.  Despite my
surprise, I continued feeding the others, because if one of the three
patches was actually accepted, code slush or no, then I really didn't
want the official libtool-2.0(.0) to have only a partly finished
implementation (only one of the three phases).  Granted, I have
implemented all three phases with only backwards-dependence:
HEAD+phase1-only works.  HEAD+phase1-and-phase2-only works. 
HEAD+all-three-phases works.   There's no functional breakage by taking
only phase1, or only phase1 and phase2.  But it strikes me as odd to do
so, else why take phase 1 at all?

Note that my original email, from last year, actually specified three
separate phases, and strongly implied that they would each be
implemented separately (e.g. three separate patches) -- although my
implementation, and theory-of-operation, of #2 was a bit different than
I originally proposed, causing #3 to differ as well.  But that's beside
the point.

----

The argz stuff: actually fixes a _bug_ that was exposed by failing mdemo
tests on cygwin, which began failing ~six months ago (I no longer
remember exactly when, nor what change in either libtool or cygwin was
the proximate cause; perhaps cygwin first began exporting the newlib
argz symbols?).  The mingw change fixes a hitherto unnoticed bug in that
the mingw wrapper executables _did not work_ -- ever.  I suspect the
upcoming MSYS-1.0.11 release with its updated coreutils and bash might
actually expose this bug, in that foo.exe will now be preferred over
foo, just like on cygwin.  So, yeah, I think these two ARE release
blockers.

The three-phase "go away pesky foo.exe/foo wrapper confusion" patches
are NOT release blockers.  That's why I said (above) 'if possible and
acceptable to
[Ralf|Gary|others]' -- using whatever stringent standard you wish to
apply.  You'd already accepted phase 1, so...if you had already decided
to accept phase 2 and phase 3 before releasing 2.0, then I wanted to do
it sooner rather than later, for outside (gcc) reasons. 

However, if you wish to delay phase 2 and phase 3 until post-2.0, that's
fine too -- and I'll code up the mingw exe wrapper fix separately.

--
Chuck