On Fri, Feb 27, 2009 at 13:14, Philip Martin <philip_at_codematters.co.uk> wrote:
> Justin Erenkrantz <jerenkrantz_at_apache.org> writes:
>> From: jerenkrantz_at_tigris.org
>> Subject: svn commit: r36153 - in trunk: . build
>> To: svn_at_subversion.tigris.org
>> Date: Thu, 26 Feb 2009 00:23:54 -0800
>> Reply-To: dev_at_subversion.tigris.org, jerenkrantz_at_tigris.org
>> Author: jerenkrantz
>> Date: Thu Feb 26 00:23:54 2009
>> New Revision: 36153
>> Remove detection for GNU libtool and always use APR's libtool (be it GNU or
>> jlibtool or whatever).
>> * configure.ac: Always enable using APR's libtool.
>> * autogen.sh, build/buildcheck.sh: Remove anything related to libtool detection.
>> * build/
>> (svn:ignore): Remove config.guess and config.sub from ignore list.
>> * build/config.guess, build/config.sub
>> (added): Take latest drops from FSF.
> Why is this a good thing to do? How do I override it and use a
> different libtool?
> I use APR provided by Debian stable; I don't know exactly which
> libtool was used to build APR but Debian stable comes with libtool
> 1.5.26. I choose to install libtool 2.2.6 since it is much faster
> and, particularly when building a debug version, libtool is a
> significant part of the Subversion build process. Forcing me to use
> APR's libtool increases the build time by 50%. I don't want to have
> to build APR in order to control the libtool used to build Subversion.
Well... the previous stuff was causing breakage. Easiest solution was
to toss all the crap out and rely on APR. We rely on APR to figure out
all the system's libraries and flags and includes to use for building.
Using it for libtool seems very appropriate.
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?
It seems a bit strange to replace one small part of the overall build
system described by APR. Maybe there is a simple way to override,
without all of the previous gunk that we used to have?
Received on 2009-02-27 13:31:52 CET