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

Re: [PATCH] update to configure.in for autoconf-2.5X

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-08-06 22:00:14 CEST

On Tue, Aug 06, 2002 at 02:11:58PM -0500, Karl Fogel wrote:
> Art Haas <ahaas@neosoft.com> writes:
> > Index: ./configure.in
> > ===================================================================
> > --- ./configure.in
> > +++ ./configure.in 2002-08-06 10:47:36.000000000 -0500
> > @@ -8,8 +8,9 @@
> > dnl Don't even think about removing this check!
> > AC_PREREQ(2.50)
> >
> > -dnl First line is *required*; sanity-checks that the our src dir exists.
> > -AC_INIT(subversion/include/svn_types.h)
> > +dnl AC_CONFIG_SRCDIR *required*; sanity-checks that the our src dir exists.
> > +AC_INIT([subversion], [0.14.0], [http://subversion.tigris.org])
> > +AC_CONFIG_SRCDIR(subversion/include/svn_types.h)

Ah. Good patch. I did this for Expat a little while back, and forgot to
bring forward similar changes.

> This means maintaining the release number in two places, because it's
> already deduced at build time from subversion/include/svn_version.h.
>
> Is there another way to do this, such that we can avoid the "two
> masters" problem?

You bet. Here is what I did in Expat:

dnl Get the version number of Expat, using m4's esyscmd() command to run
dnl the command at m4-generation time. This allows us to create an m4
dnl symbol holding the correct version number. AC_INIT() requires the
dnl version number at m4-time, rather than when ./configure is run, so
dnl all this must happen as part of m4, not as part of the shell code
dnl contained in ./configure.
dnl
dnl NOTE: esyscmd() is a GNU M4 extension. Thus, we wrap it in an appropriate
dnl test. I believe this test will work, but I don't have a place with non-
dnl GNU M4 to test it right now.
define([expat_version], ifdef([__gnu__],
                              [esyscmd(conftools/get-version.sh lib/expat.h)],
                              [1.95.x]))
AC_INIT(expat, expat_version, expat-bugs@lists.sourceforge.net)
undefine([expat_version])

>...
> From reading your paragraph, and the patch, I _sort_ of understand
> what's going on, but not quite -- it seems you haven't just changed
> the way we call AC_INIT and AC_OUTPUT (as your paragraph implies), but
> also added new calls to macros that were not called before. A
> complete log message might clear this up.

The changes are Goodness(tm), so with a bit of mods for the version number,
we can go ahead and use it. For example, if the version could not be
extracted, then we could default it to 0.x or something. But hey: note that
the translation from configure.in to configure is performed by packagers,
not end-users. As long as the packagers have GNU m4, then the right version
number will appear in there.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 21:57:13 2002

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.