[PATCH] AC_SUBST: document and test previous patch
* doc/autoconf.texi (Setting Output Variables) AC_SUBST: Mention
that variable does not overlap with macros.
* tests/base.at (AC_SUBST): New test.
Signed-off-by: Eric Blake ebl...@redhat.com
---
I went ahead and whipped something up.
doc/autoconf.texi | 3 ++-
tests/base.at | 54 ++
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index c4ebe11..b3f7a23 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -9876,7 +9876,8 @@ Setting Output Variables
If @var{value} is given, in addition assign it to @var{variable}.
The string @var{variable} is passed to @code{m4_pattern_allow}
-(@pxref{Forbidden Patterns}).
+(@pxref{Forbidden Patterns}). @var{variable} is not further expanded,
+even if there is another macro by the same name.
@end defmac
@defmac AC_SUBST_FILE (@var{variable})
diff --git a/tests/base.at b/tests/base.at
index 7979413..7530c21 100644
--- a/tests/base.at
+++ b/tests/base.at
@@ -708,3 +708,57 @@ libdir=${exec_prefix}/lib
]])
AT_CLEANUP
+
+## -- ##
+## AC_SUBST. ##
+## -- ##
+
+AT_SETUP([AC_SUBST])
+AT_KEYWORDS([AS@t@_IDENTIFIER_IF])
+
+# Check that a valid variable name is used.
+AT_DATA([configure.ac],
+[[AC_INIT([test], [1])
+AC_SUBST([1], [bar])
+AC_OUTPUT
+]])
+AT_CHECK_AUTOCONF([], [1], [], [stderr])
+AT_CHECK([grep 'not a valid shell variable' stderr], [], [ignore])
+
+AT_DATA([configure.ac],
+[[AC_INIT([test], [1])
+AC_SUBST([], [bar])
+AC_OUTPUT
+]])
+AT_CHECK_AUTOCONF([], [1], [], [stderr])
+AT_CHECK([grep 'not a valid shell variable' stderr], [], [ignore])
+
+AT_DATA([configure.ac],
+[[AC_INIT([test], [1])
+AC_SUBST([*], [bar])
+AC_OUTPUT
+]])
+AT_CHECK_AUTOCONF([], [1], [], [stderr])
+AT_CHECK([grep 'not a valid shell variable' stderr], [], [ignore])
+
+# Make sure AC_SUBST handles variables as expected.
+AT_DATA([file.in],
+[[@FOO@
+FOO
+]])
+AT_DATA([configure.ac],
+[[AC_INIT([test], [0])
+m4_define([FOO], [baz])
+AC_SUBST([FOO], [bar])
+AC_CONFIG_FILES([file])
+AC_OUTPUT
+]])
+
+AT_CHECK_AUTOCONF([], [], [], [stderr])
+AT_CHECK_CONFIGURE
+AT_CHECK([cat file], [],
+[[bar
+FOO
+]])
+
+AT_CLEANUP
--
1.7.11.2
Re: Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)
On Tue, Aug 14, 2012 at 06:57:02PM -0500, Bob Friesenhahn wrote:
AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]),
m4_esyscmd([scripts/pkginfo.sh package_version]),
m4_esyscmd([scripts/pkginfo.sh package_bugreport]))
Unfortunately, the values passed to AC_INIT are cached so even if
the configure script is run again, it uses the cached values rather
than the new values.
I've been doing a similar thing, though I do it directly in configure.ac
rather than using an external script:
AC_INIT(sbuild_m4_esyscmd_s([sed -ne
'/^Package:/{s/Package:[[:space:]][[:space:]]*//p;q}' VERSION]),
[sbuild_m4_esyscmd_s([sed -ne
'/^Version:/{s/Version:[[:space:]][[:space:]]*//p;q}' VERSION])],
[buildd-tools-de...@lists.alioth.debian.org])
In this case, the information is taken from a static file with the format:
Package: schroot
Version: 1.6.3
Release-Date: 23 Jul 2012
Released-By: Roger Leigh rle...@debian.org
Git-Tag: release/schroot-1.6.3
This is generated by the bootstrap script.
Package and Version are derived from NEWS (since this must be updated
for a release, we require the version here to be the definitive source
of the version.
The other date is taken from the release tag in git; if it's not a
release, i.e. isn't tagged, it's just left as Unreleased.
Your version is better, because it permits vanilla autoreconf to be
used. Providing that we have a stable interface for autoconf to
call an external script, packages could do whatever they wish to
provide the information. Maybe a single-argument AC_INIT which
just has a script file as its argument? However it's done, having
this standardised would be beneficial to all.
In addition to it invoking the script with arguments for
package, version and bugreport address, it might also be nice to
provide the ability to supply information for arbitrary other
stuff such as
- public git URI
- public website
- public bug tracker
- git release and distribution tags
- git branch
And perhaps also allow this to be extended by the builder/distributor,
for example with
- build date
- builder
- distribution
- distribution bug tracker etc.
These are all examples of things which are currently done by some
packages on an ad-hoc basis, but which would benefit from more
generalised support in autoconf. Maybe add a command-line option
to run additional script(s) to source supplementary/overriding
information?
On the automake side, I'm still using custom targets for git integration
with make dist which inject $(distdir) into a separate git branch and
tag that as a distribution; a separate step tags the release, which
is then distributed. If it's not possible to support directly in
automake, being able to disable tarball generation in the dist target
and do completely custom stuff there would be useful. In particular,
having a logical separation of releasing and distributing would be
good.
One thing which is currently done wrong is that some stuf, e.g.
gettext, tries to regenerate stuff at make dist time. This is
rather annoying, as it's creating updated versions of files /after/
you've tagged the release. This means you need to run make dist, then
tag, then run make dist again. While workable, it's easy to forget and
mess up the release process. When you're using a DVCS, this is the wrong
point. We only want to tag the release /after/ all sources changes have
been made and *committed*. Thus there are three steps:
1) release preparation
- updates any files e.g. gettext po files etc.
- commit any changes resulting from this step
2) release
- tags the repo with a signed release tag
3) distribution
- makes the distdir and injects it onto a distribution branch
- branch is tagged
- release tarball is obtained (if required) using git archive
to export the tagged distribution. Not needed for an all-git
workflow (e.g. future Debian git source package format).
The existing make dist does of course do everything in a single
step; but it would be nice if these were split into separate,
overridable/hookable targets, and tools like gettext updated to
run in the release prep stage.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake
On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Dynamic package version numbers with Autoconf and Automake
On 08/15/12 08:45, Bob Friesenhahn wrote: On Wed, 15 Aug 2012, Miles Bader wrote: (3) The final version info is updated (using VCS info and/or autoconf version info) at make time using a script, and when it changes, only causes a source file (e.g., version.c) to change. This means that although some things are rebuilt after a commit (version.o, and relinking of any binaries that use it), the amount of rebuilding is relatively minor while still yielding accurate info. Likewise, GraphicsMagick configures a version.h as well as a version file used for non-autotools builds under Windows. With the currently used mechanism, only the few files depending on version.h need to be rebuilt but the whole project relinks. If the project config.h was to be re-generated (seems to be necessary with new AC_INIT), then all of the source modules would need to be recompiled and relinked since everything depends on the configuration header. Bpb I've had a similar complaint when using Autotest. In my project, the test suite depends on an M4 input file that has the project version encoded in it. cat test_suite/package.m4 # Signature of the current package. m4_define([AT_PACKAGE_NAME], [my_server]) m4_define([AT_PACKAGE_TARNAME], [my_server]) m4_define([AT_PACKAGE_MINOR_VERSION], 4.18) m4_define([AT_PACKAGE_VERSION], [4.18.5]) m4_define([AT_PACKAGE_STRING], [my_server 4.18.5]) Which is created by a makefile rule as suggested in the autoconf documentation: http://www.gnu.org/software/autoconf/manual/autoconf.html#Making-testsuite-Scripts So when I change the version of the package, I autoreconf, then make then autoreconf again. Scenario #2 - I have inherited a library versioning scheme that doesn't play nice with Libtool (an absolute requirement) when the Automake name is not encoded with the version - lib_LTLIBRARIES = libmy_server-4.18.la So every time I change the version argument to AC_INIT, I have to search around my makefiles for anything that references each library and make the same changes there. So I would be very interested in a solution to these issues. Cheers, Robert ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
