Re: libtool-2.0 release

[Bob Friesenhahn]

On Fri, 3 Feb 2006, Ralf Wildenhues wrote:
> > It means that LT_WITH_LTDL in configure.ac that mentions neither
> > LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all.
> > I have a start to a fix for this.
>
> Well, so is that really a bug?  AFAIK the 1.5 docs require you to use
> AC_LIB_LTDL, _not_ AC_WITH_LTDL (that exists but isn't even mentioned in
> the docs), and AFAICS AC_LIB_LTDL *will* cause libltdl to be built: see
> the second old-am-iface.at test, which explicitly does this.  The
> updated form of AC_LIB_LTDL is LTDL_INIT, not LT_WITH_LTDL.  However,
> our current CVS HEAD documentation fails to even mention LTDL_INIT.  I
> wonder whether this is maybe a bug in documentation only?

I have not checked the latest documentation, but as I mentioned 
before, the documentation for the legacy libtool configuration macros 
should be added back to the documentation along with a note to the 
extent that they are deprecated and are subject to eventual removal. 
The fact that these older macros still work is vital to the acceptance 
of libtool 2.0.

> Well, this comment of Bob completely mystifies me:
> http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582
> I believe in that thread there were more issues mentioned.

I am intentionally using GNU sed 3.02.  It is possible that the 
mystery is related to sed versions.

> There was one other one, and from memory, I believe it goes like this:
> suppose we have a package with libltdl.  If the user does
>  --without-included-ltdl
> then I believe `-Ilibltdl' and such paths get still added to includes,
> which is wrong.
>
> I don't remember from memory whether that was for subpackage libltdl,
> or for nonrecursive, or for recursive.  Sorry.

The problem is when generating the Makefile.inc used for the 
nonrecursive libltdl build.

> > ACK.  I think we can be justifiably proud of the huge improvements we've
> > brought to the new testsuite in the last 18 months.
>
> :)  I think with about 10-20 times as much test exposure we can have
> almost well-defined semantics in libtool.

In my experience, if something has not been explicitly tested, it is 
likely to be broken.  So the improved test suite reflects actual 
improvements in libtool 2.0 itself.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/