Attn: cygport maintainer [was: Re: Libtool 2.2.2]

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> | That should be taken up with the libtool maintainers.  However, it has
[snip]
> If I need to add LT_OUTPUT already, then I might as well switch entirely
> to the LT_* macros.

True. But that is NOT required. libtool-emit-time is simply a new 
(possible backwards-incompatible) behavior change of the new libtool -- 
but one that hopefully impacts few clients.

> The compatibility AC_PROG_LIBTOOL macro should be
> just that: compatible with previous behaviour; otherwise, old packages
> WILL break. 

A very very small number. The attitude of the libtool maintainers is, 
this extremely small minority is supported via the LT_OUTPUT macro. For 
everybody else, the vast majority, AC_PROG_LIBTOOL will Just Work(tm), 
and we (they) are not going to pessimize everybody else just to support 
that small minority -- who can use the LT_OUTPUT if they really need to.

> This should not affect LT_INIT and the intended behaviour
> for the future.

The change with regards to when, during the configure process, the 
libtool script itself is generated, is a separate and orthogonal issue 
from "did you use the old A[CM]_PROG_LIBTOOL macro or the LT_INIT 
macro". Rather, the libtool-emit-time change is (one of the few) 
backwards-incompatiblities. Using the new libtool? Then the /default/ 
libtool-emit behavior has changed; simple as that.

> ~From the way you put it, it sounds like I shouldn't even waste my time
> asking upstream.  If they won't accept this, can our libtool package be
> patched accordingly, so that packages work after libtoolize as they did
> with 1.5?

Anything CAN be done, with enough developer 'tuits. The question is, is 
that wise?  I don't know where to *automatically* insert a call to 
LT_OUTPUT in Q_RANDOM_PACKAGE's configure.ac; and I can't simply revert 
to "the old way"-- because the libtool-emission mechanisms are vastly 
different from 1.5.x.  You don't know what you're asking...

> | You can continue to use
> | AC_PROG_LIBTOOL exactly as you did with libtool1.5.
> 
> OK, that makes sense.
> 
> I'm not sure exactly how widely tested 2.2 is, so I understand the
> logic.  But there are a few packages with some 2.x libtool included
> (ImageMagick comes to mind), for which 1.5 is useless, and I don't want
> to wait too long to switch.

Ack.

And Bob F. jumped to 2.2 prematurely, IMO...

> I was looking more at the autoconf/automake side of libtool, but you
> raise a good point.  Where are the ltdl changes outlined, and how many
> packages break due to those changes?

Most of the removed interfaces were removed *because* they were not 
widely used (and were ugly; couldn't support the new features, etc). The 
changes are detailed in the new libtool's .info files. You can view them 
"offline" by unpacking libtool2.2 somewhere "safe" and using 'info -f 
/explicit/path/to/libtool2.2.info'.

> If AC_PROG_LIBTOOL can be compatible, and the ltdl API changes are
> indeed minor, than libtool should be a single package, especially if
> they can't be installed in parallel (unlike ac/am).  It may be helpful
> for 2.2 to be in testing for a little while.

Well, that's one of the possibilities I raised in my other 
email...however, it really doesn't solve the problem. It just makes 
switching between 1.5 and 2.2 a little easier given our setup.exe. 
Instead of explicitly uninstalling 2.2 and installing 1.5 (or vice 
versa), you just change the version of the single 'libtool' package from 
1.5 to 2.2 (or vice versa) -- which effectively does the same thing: 
uninstall one then install the other.

> That's really too much trouble for those of us with hundreds (or
> thousands) of packages.

Well, according to Ralf (hope he doesn't mind my paraphrase of his 
private email...)

==== start Ralf ====
LT_OUTPUT: I do not know how many packages are impacted by the LT_OUTPUT 
incompatibility issue, but was so far of the impression that it would be 
rather few.  If that impression is wrong, then it's certainly a good 
idea to let libtool at gnu dot org know about this.

LTDL API CHANGES: clients just need to cope.  If there are clients out 
there for which it would be an unduly amount of work or hassle, we'd 
like to know about it.  Actually, even more than with LT_OUTPUT, I 
believe that problems should be far and few between here.
==== end Ralf ====

The remainder of Ralf's email would tend to support this portion of your 
position: consolidate to a single 'libtool' package, make 2.2 the 'test' 
version, and leave it there until most of the maintainers have had a 
chance to see what issues arise with their packages. Then, and only 
then, bump the 2.2 version to current.

His suggestion was: hey, just install libtool2.2 and rip through all 
your packages (...er, all 1300 of them? ...) and most of them ought to 
be fine.  If more than a handful are not, then we (the libtool devs) 
need to know.

> | But this sort of thing is only necessary for those (hopefully rare)
> | packages where it actually MATTERS which version of libtool you use.
> 
> That's also pretty complicated.  When would a package NOT work with 2.2?

Yes it is. The problems would occur if the client needed a lot of work 
to come into compliance with the new LTDL API. The LT_OUTPUT thing is 
really very easy to fix for a given package. (And, according to Ralf, 
the LT_OUTPUT thing, while rarely needed, is much more probable to arise 
than LTDL API issues.  That's good.  I like my more common problems to 
be easy to fix. And I like ALL my problems to be rare. Like my steak.)

> | Even so, I hate to go back to the old "libtool-stable/libtool-devel"
> | paradigm, 
>
> I don't want to go there again either.

Okay. We're agreed. <g>

> To summarize:
> *) AC_PROG_LIBTOOL 2.2 should be fully compatible with 1.5 by calling
> LT_OUTPUT.  Patching libtool in this way will save all of us patching
> more packages in the future.

But it is not that simple.  The "old" way of generating/emitting libtool 
was not simply "call some LT_OUTPUT-like macro at the "end" of 
AC_PROG_LIBTOOL"; that's far too early.  And in almost all cases, 
waiting until AC_OUTPUT() is fine.

Besides, libtool-2.2 compatibility patches are the sort of thing 
upstream maintainers like to see...

> *) 1.5 and 2.2 aren't parallel-installable, nor should we imagine they
> will be in the near future.  In that case, there should be only one
> libtool package, with 2.2 in testing for now, and maintainers strongly
> encouraged to test.

Well, Ralf seems to agree.  I'd like to hear from a few other 
maintainers before taking that plunge though. (For now, just don't 
install the "new" libtool2.2 package, and you'll be fine).

> *) In the meantime, please remove the libtool1.5 dep from cygport, as
> long as one of the libtools are pulled in by autoconf or automake.

Well, no -- autoconf doesn't need libtool, and neither does automake. My 
point in the earlier email was that cygport *itself* doesn't really need 
libtool either.  libtool *may* be a build-depends of some other package 
that you USE cygport to build, but with an appropriately coded .cygport 
you can use cygport without libtool at all.

Thus, libtool is not required: by cygport, it is merely optional and 
highly recommended.  That way, cygport doesn't need to specify exactly 
which VERISON of libtool is recommended. :-)

So, "please remove the libtool1.5 dep from cygport. Full stop."

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/