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

Re: Building subversion with libtool 1.4

From: Branko Èibej <brane_at_xbc.nu>
Date: 2001-07-03 22:54:41 CEST

Mo DeJong wrote:

>On 3 Jul 2001, Jon Trowbridge wrote:
>
>>* The patch breaks building with libtool 1.3.5.
>>
>
>...
>
>>* I used autoconf 2.13; autoconf 2.50 won't work. (I've had problems
>> with 2.50 with other packages as well.)
>>
>
>This seems like a good time to talk about autoconf 2.50.
>This new release of autoconf fixes a huge number of
>problems and it finally makes cross compiling workable.
>
>While using the new autoconf has its benefits, there are
>also some downsides. People will complain and complain
>about the fact that they can no longer use autoconf 2.13
>once things have been upgraded to autoconf 2.50. It
>is important to "fight the urge" to make the build
>system work with multiple versions of the build tools.
>It seems doable at first, but it ends up causing no
>end of trouble since it introduces yet another variable
>that needs to be accounted for. Someone will come along
>and file a bug report like "This thing is broken" and
>after a lot of wasted effort it will be tracked down
>to a diff between autoconf 2.50 and 2.13.
>
This worries me; see below.

>To avoid all that, I suggest we add the following to
>the top of subversion's configure.in.
>
>AC_PREREQ(2.50)
>
>The main thing standing in the way of this is the fact
>that anyone wanting to build subversion would need to
>download and install autoconf 2.50. That is a valid
>issue, but it is one that we should solve another way.
>I suggest that instead of forcing folks to run ./autogen.sh
>before running, the autoconf generated files (like ./configure)
>should be stored in the CVS. That may seem like blasphemy
>to some, but there are good reasons for it.
>
I'd be willing to try this. GCC does this, and it seems to work. Of
course, the catch here is that GCC happens to be a ling-living project
with literally hordes of users and developers that use CVS or snapshots
all the time. Subversion isn't quite in that league yet.

>For one thing, anyone can build the tree after a checkout.
>Since there is no need to have autoconf and libtool installed,
>folks will not complain about needing to upgrade to the new
>autoconf. Folks that want to make changes to the build scripts
>will need to upgrade, but there will only be a few of these folks.
>Putting the ./configure script in the CVS makes it easy to pull
>down a build-able tree from 6 months ago.
>
This is indeed a very good argument, but it's unrelated to whether we
use autoconf 2.13 or 2.50.

>This tree will not
>depend on your locally installed (and possibly locally modified)
>tools in any way, so it is easy to reproduce previous results
>without worry that installed tools have an effect on the results.
>
>What do folks think? This is both a technical and a political
>question since every package that subversion depends on will
>also need to be upgraded before we really see the benefits
>of autoconf 2.50. I am willing to do much of the work, but
>before the way comes the will.
>
I'm worried about one thing: I work on other projects besides Subversion
every now and then. I can't expect all of these projects to accept
upgrading to autoconf 2.50, but you say it's inherently incompatible
with 2.13. What do I do then? Have two copies of the tools installed,
and switch betweent them with $PATH magic? I'd like to avoid that if
there's another way.

    Brane

-- 
Brane �ibej
    home:    <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:    <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
      ACM:   <brane_at_acm.org>            http://www.acm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:32 2006

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.