[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r36153 - in trunk: . build

From: Philip Martin <philip_at_codematters.co.uk>
Date: Fri, 27 Feb 2009 19:28:48 +0000

Justin Erenkrantz <justin_at_erenkrantz.com> writes:

> 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.

That appears to be a bug in your X server or terminal. Does it happen
on any other machine?

I don't really understand your situation: are you building APR with
libtool 2.x or 1.x? If you are using 2.x then Subversion should be
able to do the same as APR. If you are using 1.x then you should be
able to use that to build Subversion. Perhaps you are not building
APR at all and getting from APR a version of libtool that you don't
have installed? If so you should be able to install that version of
libtool.

> 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.

The code you removed worked perfectly well on my machine; it's better
than the current code as far as I am concerned.

>>> 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

How do I reverse the 50% increase in build time?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1240489
Received on 2009-02-27 20:29:12 CET

This is an archived mail posted to the Subversion Dev mailing list.