On Fri, Feb 27, 2009 at 9:32 AM, Philip Martin <philip_at_codematters.co.uk> wrote:
> That doesn't work:
>
> - It's not sticky so it's not as good as a configure option.
>
> - The /path/to/your/libtool that I want to use is the libtool script
> generated in the build directory but that no longer exists.
> (/usr/bin/libtool is not a solution because it's not the same as the
> script generated by running configure; it's no faster then the apr
> version.)
>
> Instead of making --enable-experimental-libtool the default and
> removing the alternative could you not simply have changed the default
> and left the old code in place?
No, because libtool 2.x is completely broken wrt autoconf. You can no
longer conditionally use GNU libtool in an autoconf script. I spent
over an hour trying to fix it, and I kept failing - having my X server
crash because libtool is blowing up autoconf is simply not an
acceptable solution. The 'right' solution requires a whole lot of
platform-specific junk - rather than continuing to add needless bloat
related to supporting libtool, I think the right solution is to punt
on this and let APR eventually figure it out.
>> If APR pointed you at an old expat library, what would you do? Upgrade APR.
>> If APR pointed you at an old libtool, what would you do?
>
> I don't expect APR to point at libtool; it's quite possible to build
> against APR without using libtool.
APR always provides it's copy of libtool. We don't need to replicate
the logic to create a libtool. Given how much code Subversion had to
create in order to support a variety of libtool versions, I think the
change is more than justified. -- justin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1240284
Received on 2009-02-27 19:36:49 CET