You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jon Trowbridge <tr...@ximian.com> on 2001/07/03 06:46:12 UTC
Building subversion with libtool 1.4
Attached to this message are two files that can be used to build
subversion with libtool 1.4. One file (subversion-lt1.4-2.patch) is a
patch against subversion CVS. The second (svn-install.sh.in) should be
placed in the top-level subversion directory; it is a template for a
replacement install.sh script that ascends to the top-level source
directory before doing anything.
Caveats:
* The patch breaks building with libtool 1.3.5.
* You need to "make; make install" for this to work. Just doing
"make install" fails. This seems to be a problem with the apr
build, and may be libtool 1.4-related.
* After building and installing, you need to manually install libmm
with "cd apr/shmem/unix/mm; make install". This appears to be a bug
in the apr build, and does not seem to be libtool 1.4-related.
* I used autoconf 2.13; autoconf 2.50 won't work. (I've had problems
with 2.50 with other packages as well.)
The replacement build script is a pretty hacky solution to the problem.
I'm not proposing it as a permanent fix, but rather as a stop-gap
measure to allow people (i.e. me) to play with subversion until some of
the kinks in the build system get worked out.
Enjoy,
-JT
Re: Building subversion with libtool 1.4
Posted by Jon Trowbridge <tr...@ximian.com>.
On 03 Jul 2001 16:04:00 -0500, Karl Fogel wrote:
> Mo DeJong <md...@cygnus.com> writes:
>
> By the way, I'd still like to know to know exactly what problems Jon
> Trowbridge was having with 2.50 before we start requiring it in
> Subversion. I got the impression from his mail that he didn't share
> your high opinion of 2.50, but don't know the specifics yet.
I don't have a high or a low opinion of 2.50. All I know is that some
builds just mysteriously fail with it --- including the build for the
project I get paid to work on (Evolution).
> > 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.
I agree. This is why I think dropping support for libtool 1.3.x makes
sense; why continue to maintain hacky bug work-arounds?
However, the fact that autoconf 2.50 breaks builds is problematic.
Maybe necessary, but problematic.
> > Putting the ./configure script in the CVS makes it easy to pull
> > down a build-able tree from 6 months ago. 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.
I agree with the others who have argued that putting these files in CVS
is a Bad Idea[tm]. This is a real issue, though; it is too bad that the
autoconf/automake/libtool don't provide an easy way to have multiple
versions installed under the same prefix. (Wouldn't it be nice if
autoconf, libtool, etc. were just version-independent front-ends that
could be invoked in a "libtool --use-version 1.3.5" fashion...)
-JT
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Karl Fogel <kf...@collab.net>.
"Paul D. Smith" <ps...@gnu.org> writes:
> We obviously made absolutely no comments concerning the reliability
> etc. of the code in a given nightly snapshot; really the snapshots are
> more for developers who don't have or want to install the development
> tools--obviously these developers didn't do CVS commits since they were
> working from a dist tarball; they would send patches to the committers
> for application.
The nightly snapshots are something we should have (once we're in
alpha), for exactly the reasons you give, I completely agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by "Paul D. Smith" <ps...@gnu.org>.
%% Karl Fogel <kf...@collab.net> writes:
kf> If we keep autogenerated files, such as configure, under revision
kf> control, people must manually remember to actually do the
kf> regeneration before committing. (Attempts to automate this
kf> requirement usually fall flat, because not *every* modification to
kf> a `foo.in' file needs to result in a regenerated `foo' -- only
kf> semantically important changes).
I'm not a Subversion developer, so take this as a comment from the
peanut gallery:
I've been involved with a project that decided to put configure,
Makefile.in, etc. in CVS and it was bad mojo. Very annoying. Stuff
broke all the time. Even more annoying than forgetting to rebuild the
files, on some systems these files would change for no apparent, or
important, reason, and then you'd get "dueling commits" where one person
would commit some changes that had nothing to do with configure/etc.,
but modified all the Makefile.in's in some meaningless way, then another
person would commit something that changed them all back, etc.
We took these files back out again after a few months of cursing (and
_that_ was hard, too, with CVS--can't wait for Subversion to be stable
;).
What we did instead was create nightly snapshots using an automated
script that did a "cvs update" then "make dist" (basically), then the
resulting tar file was stuck into an anonymous FTP area.
If the script failed, email was sent to the devel list. This is a nice
feature in and of itself, to get a nightly sanity build.
We obviously made absolutely no comments concerning the reliability
etc. of the code in a given nightly snapshot; really the snapshots are
more for developers who don't have or want to install the development
tools--obviously these developers didn't do CVS commits since they were
working from a dist tarball; they would send patches to the committers
for application.
Just another idea...
--
-------------------------------------------------------------------------------
Paul D. Smith <ps...@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Jon Trowbridge <tr...@ximian.com>.
On 08 Jul 2001 21:56:20 -0700, Mo DeJong wrote:
>
> Ok, let's just assume for a moment that upgrading will break
> every build and that some amount of work will be needed to
> get each and every package to work with the new version. Is
> there some alternative? You can't just stick with 2.13
> forever. Software changes and things break. It is a fact
> of life.
Yes, but it is also (IMO) bad manners to break things in critical
components without:
* Making sure everyone knows that stuff will break.
* Clearly telling people how to unbreak it.[1]
Not that autoconf is the first program ever to be
non-backwards-compatible, nor will it be the last...
People will eventually move to 2.50, sure. But they may dig their heels
in and keep using 2.13 for a long time.
> It is not that I have a problem with the complaints you
> mentioned. It is just that they do not matter in this context.
> Why would problems with the GNOME packages matter to developers
> of subversion? The subversion project depends on apr,
> the apache web server, neon, expat, berkeley db, and
> python.
I mention the GNOME issue only because it is indicative of the reasons
why autoconf 2.50 is not being rapidly accepted by the community.[2]
And even if the entire subversion dependency tree builds fine w/ 2.50,
requiring it puts a burden on developers[3] who occasionally need to
build things outside of that small set of dependencies.
I'm certainly not trying to flame the autoconf developers, who do
execellent work and have one of the more thankless jobs out there. I'm
just saying that the "take your medicine" approach of adding
AC_PREREQ(2.50) at this time has some costs, and might continue to have
costs for quite a while.
-JT
[1] I've looked through the autoconf 2.50 package looking for a "porting
guide" or something like that, but haven't found anything. If
something like that is in there and you could tell me where to find
it, or if you could refer me to a web page or mailing list post or
something with that kind of info on it, I'd be greatly appreciative.
[2] And for the record, I think that GNOME should move to 2.50. But
several people have found it's breaks-everything-in-sight qualities
somewhat distressing, so I don't know when it is going to happen.
[3] When I say "developers", I of course really mean "me". :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Mo DeJong <md...@cygnus.com>.
On 8 Jul 2001, Jon Trowbridge wrote:
> On 06 Jul 2001 12:25:27 -0700, Mo DeJong wrote:
> > That seems to be an ongoing problem. People run something with
> > the new autoconf, it does not work, they don't bother to investigate,
> > then they tell other people that autoconf 2.50 has "issues".
> > Often, it is the project's incorrectly written macros that are
> > to blame. I had to track down a number of strange quoting
> > errors while upgrading another package. It was no fun, but
> > it was also not autoconf's fault.
>
> Well, I don't really know if autoconf can refuse *all* of the blame
> here. The topic of switching to autoconf 2.50 has come up a few times
> over at the GNOME project, but the problem is that it breaks pretty much
> *ALL* of our builds. If not every single one, it is the vast majority
> of them. Fixing them all will be a *big* job, particularly since
> autoconf doesn't provide a "migrating from 2.13 to 2.50" doc.[1]
Ok, let's just assume for a moment that upgrading will break
every build and that some amount of work will be needed to
get each and every package to work with the new version. Is
there some alternative? You can't just stick with 2.13
forever. Software changes and things break. It is a fact
of life.
It is not that I have a problem with the complaints you
mentioned. It is just that they do not matter in this context.
Why would problems with the GNOME packages matter to developers
of subversion? The subversion project depends on apr,
the apache web server, neon, expat, berkeley db, and
python. Since GNOME software is not part of this
dependency tree, I just don't see how any of this matters.
If you have specific complaints about autoconf 2.50, why
not direct them to autoconf@gnu.org?
Mo DeJong
Red Hat Inc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Jon Trowbridge <tr...@ximian.com>.
On 06 Jul 2001 12:25:27 -0700, Mo DeJong wrote:
> That seems to be an ongoing problem. People run something with
> the new autoconf, it does not work, they don't bother to investigate,
> then they tell other people that autoconf 2.50 has "issues".
> Often, it is the project's incorrectly written macros that are
> to blame. I had to track down a number of strange quoting
> errors while upgrading another package. It was no fun, but
> it was also not autoconf's fault.
Well, I don't really know if autoconf can refuse *all* of the blame
here. The topic of switching to autoconf 2.50 has come up a few times
over at the GNOME project, but the problem is that it breaks pretty much
*ALL* of our builds. If not every single one, it is the vast majority
of them. Fixing them all will be a *big* job, particularly since
autoconf doesn't provide a "migrating from 2.13 to 2.50" doc.[1]
I can understand why the autoconf people would want to get rid of the
need for crufty hacks, but I can't understand why the autoconf 2.50
release announcement didn't say, in big letters, "Autoconf 2.50 will, in
all probability, break your builds. To fix it, do X, Y and Z".
The autotools have a (IMO pretty much deserved) opinion for being
obscure... I personally like 'em a great deal, but there is no denying
that in the past it has taken a lot of black magic to get certain things
to work properly. And I'm all for sets to reduce the amount of black
magic... but breaking 90% of the builds[2] out there is not a recipe for
rapid acceptance of the new version.
-JT
[1] To the best of my knowledge, that is.
[2] 90% is an estimate. However, of the four or five things
that I've tried to build w/ autoconf 2.50, *none* have worked.
So I think that it is a generous estimate. :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Mo DeJong <md...@cygnus.com>.
On 3 Jul 2001, Karl Fogel wrote:
> Mo DeJong <md...@cygnus.com> writes:
> > 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.
>
> Can you first make Jon Trowbridge's patch (for libtool 1.4
> compatibility) work with autoconf 2.50? Currently we have to choose
> between being up-to-date with libtool vs up-to-date with autoconf. :-)
Ok, I have done that. I posted a patch to the apr dev list
that fixes apr so that it works with autoconf 2.50 and
libtool 1.4. I then built subversion (with the libtool
patch to remove the .libs hacks) and it worked just fine.
...
> By the way, I'd still like to know to know exactly what problems Jon
> Trowbridge was having with 2.50 before we start requiring it in
> Subversion. I got the impression from his mail that he didn't share
> your high opinion of 2.50, but don't know the specifics yet.
That seems to be an ongoing problem. People run something with
the new autoconf, it does not work, they don't bother to investigate,
then they tell other people that autoconf 2.50 has "issues".
Often, it is the project's incorrectly written macros that are
to blame. I had to track down a number of strange quoting
errors while upgrading another package. It was no fun, but
it was also not autoconf's fault.
> I don't think anyone feels a need to work with a wide range of
> versions of each tool. Working with the latest stable release of each
> tool is okay. But currently we have a conflict even there...
I don't see that there is any other option. Both autoconf 2.13
and libtool 1.3 have some serious bugs that are currently
worked around in the build system. These workarounds cause
other problems like static builds not working. By upgrading,
we are trading a known set of bugs for a unknown set of bugs.
My take on upgrading build components like this is, the
sooner the better. That gives people more time to build
on strango systems and report any problems they run into.
cheers
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Karl Fogel <kf...@collab.net>.
Mo DeJong <md...@cygnus.com> writes:
> 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.
Can you first make Jon Trowbridge's patch (for libtool 1.4
compatibility) work with autoconf 2.50? Currently we have to choose
between being up-to-date with libtool vs up-to-date with autoconf. :-)
Regarding the larger question:
So far, Subversion has had this policy:
1. Developers (i.e., people who check out source trees) can be
asked to have the right versions of the right tools installed on
their systems. This includes not only autoconf, but python (for
the tests), and possibly other stuff I'm forgetting.
Note that one doesn't have to be a terribly involved developer
to learn to run autogen.sh before running configure. Or just
learn to read INSTALL. :-)
2. Others who want to build from source can get a tarball created
from "make dist". Those tarballs have all the files
pregenerated -- they're essentially the Subversion tree after
autogen.sh has been run. They are intended to be the
"out-of-the-box" experience that users expect.
If we keep autogenerated files, such as configure, under revision
control, people must manually remember to actually do the regeneration
before committing. (Attempts to automate this requirement usually
fall flat, because not *every* modification to a `foo.in' file needs
to result in a regenerated `foo' -- only semantically important
changes).
In the CVS tree, I know of more than one instance where someone,
sometimes myself, changed configure.in and then forgot to commit a new
configure along with it. Usually these oversights are caught early
and do not result in great inconvenience for anyone, I must admit, so
it's not a showstopper. But is there a compelling reason to start
storing the autogenerated files? Your AC_PREREQ(2.50) idea seems like
a good one, and still only affects developers (as defined above).
By the way, I'd still like to know to know exactly what problems Jon
Trowbridge was having with 2.50 before we start requiring it in
Subversion. I got the impression from his mail that he didn't share
your high opinion of 2.50, but don't know the specifics yet.
I don't think anyone feels a need to work with a wide range of
versions of each tool. Working with the latest stable release of each
tool is okay. But currently we have a conflict even there...
-Karl
> 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.
>
> 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.
>
> 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 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.
>
> Mo DeJong
> Red Hat Inc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Building subversion with libtool 1.4
Posted by Mo DeJong <md...@cygnus.com>.
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
Re: Building subversion with libtool 1.4
Posted by Branko Čibej <br...@xbc.nu>.
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: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@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
Re: Building subversion with libtool 1.4
Posted by Mo DeJong <md...@cygnus.com>.
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.
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.
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 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.
Mo DeJong
Red Hat Inc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org