[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: Mo DeJong <mdejong_at_cygnus.com>
Date: 2001-07-04 00:34:02 CEST

On Tue, 3 Jul 2001, Branko =?ISO-8859-2?Q?=C8ibej?= wrote:

...

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

True. I am claiming it is a way to keep from hearing complaints
from people that don't want to install the new autoconf before
building subversion. Same goes for upgrading to libtool 1.4.

...

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

There should be nothing "inherently incompatible" between the two
versions of autoconf. It is just that the way things should be
and the way they really are often differ.

> 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

Well, I am not sure there is another way. If you leave out
the AC_PREREQ(2.50), then someone will come along and run
./autogen.sh with autoconf 2.13. It will seem to work for
them and they will check it in. This will break the
build for someone else, but the original developer
who broke it will not know.

Mo

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