Mo DeJong <mdejong@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
Received on Sat Oct 21 14:36:32 2006