[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 21:14:34 +0000

Justin Erenkrantz <jerenkrantz_at_apache.org> writes:

> On Fri, Feb 27, 2009 at 11:28 AM, Philip Martin
> <philip_at_codematters.co.uk> wrote:
>> That appears to be a bug in your X server or terminal.  Does it happen
>> on any other machine?
>
> See what happens when you pass --enable-experimental-libtool prior to
> my revision. The produced configure script is invalid. libtool 2.x's
> macros corrupt autoconf's internal states so that it fails to produce
> config.status.

I'm a little upset that you strip out code I want to use simply
because your switch doesn't work :-(

Anyway, it appears to be fixed by this patch (note the existing
comment indicating that the line I moved was a bit dodgy)

Index: ../src/configure.ac
===================================================================
--- ../src/configure.ac (revision 36152)
+++ ../src/configure.ac (working copy)
@@ -173,6 +173,7 @@
   AS_HELP_STRING([--enable-experimental-libtool],[Use APR's libtool]),
   [experimental_libtool=$enableval],[experimental_libtool=no])
 
+ifdef([LT_INIT],[LT_INIT],[AC_PROG_LIBTOOL])
 if test "$experimental_libtool" = "yes"; then
   echo "using APR's libtool"
   sh_libtool="`$apr_config --apr-libtool`"
@@ -181,8 +182,6 @@
 else
   sh_libtool="$abs_builddir/libtool"
   SVN_LIBTOOL="\$(SHELL) $sh_libtool"
- dnl libtoolize requires that the following line not be indented
-ifdef([LT_INIT], [LT_INIT], [AC_PROG_LIBTOOL])
 fi
 AC_SUBST(SVN_LIBTOOL)

>
>> 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.
>
> I don't use GNU libtool. It is evil - for reasons exactly like this...
>
>> The code you removed worked perfectly well on my machine; it's better
>> than the current code as far as I am concerned.
>
> No, it's not.

>> How do I reverse the 50% increase in build time?
>
> I explained how to do so earlier - via make-time parameters.

It's not sticky. I don't have the generated libtool file because you
removed the code that generates it.

> If that
> doesn't appease you, create a configure patch to let you specify a
> hard-coded path to libtool to configure.

I don't have the generated libtool file because you removed the code
that generates it.

> Or, point APR at your
> version of libtool.

I don't want building APR to be the only way to use my system's
libtool. Does APR build with libtool 2.x?

> IMO, all of those are better solutions than
> having to keep adding bloat to Subversion to support the whims of the
> libtool maintainers. -- justin

I'm not a libtool/autoconf expert but it appears that the problem was
(at least partly) caused by the code implementing your switch.

Could you confirm whether the patch above is an acceptable solution?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1240893
Received on 2009-02-27 22:15:01 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.