Re: using color-tests backwards-portably
Hi Jim,
* Jim Meyering wrote on Thu, Aug 13, 2009 at 08:29:21AM CEST:
[...]
systems with automake older than 1.11.
On those systems, it's fine to ignore or disable these
two unsupported options.
Yes. Often, automake's rejection of unsupported options is stricter
than it would need to be. Unfortunately, I don't know of a general way
to solve that, as just ignoring (and warning about) them is definitely
not strict enough: some options cause incompatible behavior that may be
desired.
I proposed a configure.ac-modifying solution,
https://www.redhat.com/archives/libguestfs/2009-August/msg00160.html
but it's too ugly.
Can you think of another way?
I think Automake should provide an API to allow users to say if the
Automake version is = X, then expand this configure.ac code. I think
that would be general enough (it could use Automake conditionals to
adjust Makefile.am files, it could check for = X and not = X+1 to
enforce exact versions (or we could just provide a general version
compare function) and it could then call AM_INIT_AUTOMAKE with the
appropriate options). Also, it would be explicit enough for the
developer to be conscious about not using this by accident.
However, it would likely allow fool any tools that directly grepped the
configure.ac files for AM_INIT_AUTOMAKE invocations, instead of using
autom4te --language=Autoconf-without-aclocal-m4 --trace=AM_INIT_AUTOMAKE
and even that would probably not give the right answer then (as
aclocal.m4 contents will be needed in order to provide it).
The initial patch below ought to improve the situation for future
Automake versions (but unfortunately not for past ones). With it,
you will be able to write code like
AM_VERSION_PREREQ([1.12],
[# this code assumes Automake 1.12
AM_INIT_AUTOMAKE([foreign fancy-new-option])],
[# this code does not assume 1.12
AM_INIT_AUTOMAKE([foreign])])
Does that look like a viable approach to people?
Of course, just like m4_version_prereq, it violates the Autoconf
principle that you should test the actual feature you would like to use,
rather than some version number. I don't know how to solve that without
another layer of indirection, which would amount to something you
outline in the URL above. (The other rationale why it may not be so bad
here is that luckily, distros seem to provide pretty much plain upstream
Automake these days, without many patches tacked on and features added,
so that a version number actually retains some meaning.)
What you can do in the meantime to have things work well for you with
git Automake (once that provides AM_VERSION_PREREQ) is something like
m4_ifdef([AM_VERSION_PREREQ],
[ use AM_VERSION_PREREQ like above ... ],
[ backward compat code ... ])
and you could even extend the idea to work back to 1.11 by testing for
some macro that was new in 1.11, such as AM_SILENT_RULES or AM_COND_IF.
However, there is a glitch: in case these macros are defined, i.e., the
version is = 1.11, you have to also actually use them in your
configure.ac, so that not only aclocal (who searches in the
.../share/aclocal-X.Y directory by default) finds them as defined, but
also actually includes their definition into the aclocal.m4 file, so
that a subsequent autoconf (who doesn't search .../share/aclocal-X.Y)
finds them defined, too. Clear?
As an unrelated side note, we don't use @defmac to define our macros,
which can cause bugs when used with @dvar on a @-continued definition
line, in the manual. This should be fixed.
Cheers,
Ralf
New macro AM_VERSION_PREREQ.
* m4/amversion.in (_AM_AUTOMAKE_VERSION): New define.
* m4/prereq.m4 (AM_VERSION_PREREQ): New file, new macro,
with code taken from Autoconf's m4_version_prereq.
* tests/prereq.test: New test.
* tests/Makefile.am: Adjust.
* doc/automake.texi (@dvar): New texinfo macro, taken from
Autoconf.
(Public Macros): Document AM_VERSION_PREREQ.
* NEWS: Update.
Based on suggestion from Jim Meyering.
diff --git a/NEWS b/NEWS
index 7e14ed8..fe11327 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
New in 1.11a:
+* Miscellaneous changes:
+
+ - New macro AM_VERSION_PREREQ to allow expanding different code at M4 run
+time based upon the Automake version used.
+
Bugs fixed in 1.11a:
* Bugs introduced by 1.11:
diff --git a/doc/automake.texi b/doc/automake.texi
index b3f4a76..9a489ef 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -15,6 +15,14 @@
@r...@var{\varname\}@r{]}
@end macro
+...@c @dvar(ARG, DEFAULT)
+...@c ---
+...@c The ARG is an optional argument, defaulting to DEFAULT. To be used
+...@c for macro arguments in their documentation (@defmac).
+...@macro dvar{varname, default}
+...@r{[}@var{\varname\} = @samp{\defaul...@r{]}@c
+...@end macro
+
@copying
This manual is for @acronym{GNU} Automake (version @value{VERSION},
@@ -3896,6 +3904,15 @@
Re: avoid a 1-second sleep in every configure script
Ralf Wildenhues wrote: * Jim Meyering wrote on Thu, Jul 30, 2009 at 04:20:52PM CEST: I noticed (by inspection, since I was looking at AM_SANITY_CHECK) the unconditional 1-second sleep in coreutils' configure script, and realized that it'd be easy to avoid it on modern systems: either because configure was created more than a second before, or because the file system supports subsecond time stamps. I deliberately chose not to use ls, because parsing its output is not worth the trouble. Could that bring any more portability though? IOW, is there a portable (not limited to coreutils) way to get at subsecond time stamps? Hi Ralf, Thanks for the review. You can get subsecond time stamps via GNU ls' --full-time option, but if you have that version of ls, you probably also have coreutils' stat program. If you really want to go for it, Perl is probably the most portable tool. I haven't tried. After all, it's just 1 second, and not worth the added complexity. ... +am_sanity_d1=`stat --format=%y conftest.file 2/dev/null` || am_sleep=1 +am_sanity_d2=`stat --format=%y $srcdir/configure 2/dev/null` || am_sleep=1 'info Autoconf Assignments' tells me that I shouldn't rely upon the exit status of an assignment, due to some arcane shells. IIUC then this Good catch. So let's cater also to those um, arcane, shells ;-) Updated patch that does not rely on that, below. should not cause a semantic change here; but that is a bit non obvious, and makes me wonder why you need the am_sleep=1 case at all. The other very very minor issue is that this forks twice more also on slow-fork non-GNU systems, where it then also sleeps. We can probably ignore this. I agree. Consider that part of the sleep penalty. From 3cb8feacb35d9a547fb5bf36ce1feab706aff063 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 30 Jul 2009 15:55:04 +0200 Subject: [PATCH] AM_SANITY_CHECK: avoid a 1-second sleep, if possible * m4/sanity.m4 (AM_SANITY_CHECK): Use stat to compare timestamps. Perform the 1-second sleep only if necessary. --- ChangeLog|6 ++ m4/sanity.m4 | 24 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/ChangeLog b/ChangeLog index bab1dcb..f8c392e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2009-07-30 Jim Meyering meyer...@redhat.com + + AM_SANITY_CHECK: avoid a 1-second sleep, if possible + * m4/sanity.m4 (AM_SANITY_CHECK): Use stat to compare timestamps. + Perform the 1-second sleep only if necessary. + 2009-07-08 Jim Meyering meyer...@redhat.com manual: fix a trivial grammar error. diff --git a/m4/sanity.m4 b/m4/sanity.m4 index 3d2f304..a16162e 100644 --- a/m4/sanity.m4 +++ b/m4/sanity.m4 @@ -1,21 +1,37 @@ # Check to make sure that the build environment is sane.-*- Autoconf -*- -# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008 +# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005, 2008, 2009 # Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. -# serial 5 +# serial 6 # AM_SANITY_CHECK # --- AC_DEFUN([AM_SANITY_CHECK], [AC_MSG_CHECKING([whether build environment is sane]) -# Just in case -sleep 1 +# We want conftest.file to have an mtime newer than configure. +# On some file systems we may have to sleep a second to ensure that. +# On others, with subsecond timestamp resolution, there is no need. +# Sleep only if a stat invocation produces no output, or if the +# time stamps are identical. echo timestamp conftest.file +am_sleep=1 +am_sanity_d1=`stat --format=%y conftest.file 2/dev/null` +am_sanity_d2=`stat --format=%y $srcdir/configure 2/dev/null` +test -n $am_sanity_d1\ + test -n $am_sanity_d2 \ + test $am_sanity_d1 != $am_sanity_d2 \ + am_sleep=0 + +if test $am_sleep = 1; then + sleep 1 + echo timestamp conftest.file +fi + # Reject unsafe characters in $srcdir or the absolute working directory # name. Accept space and tab only in the latter. am_lf=' -- 1.6.4.174.gc193a
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: I think Automake should provide an API to allow users to say if the Automake version is = X, then expand this configure.ac code. I think that would be general enough (it could use Automake conditionals to adjust Makefile.am files, it could check for = X and not = X+1 to enforce exact versions (or we could just provide a general version compare function) and it could then call AM_INIT_AUTOMAKE with the appropriate options). Also, it would be explicit enough for the developer to be conscious about not using this by accident. As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. -- Ben Pfaff http://benpfaff.org
Re: using color-tests backwards-portably
Hello Ben, * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST: As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. Yes, the idea sounds better. But without also exposing something like AM_SET_OPTION, it would not scale: with the above, you might have exponentially many cases to cater to as user (e.g., 8 for 3 features, if you really want to be fully version-agnostic by ignoring that feature X was introduced after feature Y). One major detail of this idea is that now, aclocal or the macro code supplied with Automake would need to know about the set of options that are supported. It doesn't do so now; only _process_option_list in lib/Automake/Options.pm used at automake run time knows. Also, the set of options isn't just a set of fixed strings, but includes some regexps. I would hate to have to duplicate this functionality in m4, esp. since we definitely also need it at automake run time for those options listed in the AUTOMAKE_OPTIONS Makefile.am variable. Cheers, Ralf
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST: As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. Yes, the idea sounds better. But without also exposing something like AM_SET_OPTION, it would not scale: with the above, you might have exponentially many cases to cater to as user (e.g., 8 for 3 features, if you really want to be fully version-agnostic by ignoring that feature X was introduced after feature Y). Well, I suppose that something like this would work: AM_INIT_AUTOMAKE([foreign AM_OPTIONAL_FEATURE([color-tests])]) where AM_OPTIONAL_FEATURE expands to its argument if that feature is supported and to the null string otherwise. (I don't understand the m4 quoting rules well enough to know whether I have the quoting right here.) One major detail of this idea is that now, aclocal or the macro code supplied with Automake would need to know about the set of options that are supported. It doesn't do so now; only _process_option_list in lib/Automake/Options.pm used at automake run time knows. Also, the set of options isn't just a set of fixed strings, but includes some regexps. OK. -- Ben Pfaff http://benpfaff.org
Re: using color-tests backwards-portably
Hi Jim,
* Jim Meyering wrote on Thu, Aug 13, 2009 at 08:29:21AM CEST:
[...]
systems with automake older than 1.11.
On those systems, it's fine to ignore or disable these
two unsupported options.
Yes. Often, automake's rejection of unsupported options is stricter
than it would need to be. Unfortunately, I don't know of a general way
to solve that, as just ignoring (and warning about) them is definitely
not strict enough: some options cause incompatible behavior that may be
desired.
I proposed a configure.ac-modifying solution,
https://www.redhat.com/archives/libguestfs/2009-August/msg00160.html
but it's too ugly.
Can you think of another way?
I think Automake should provide an API to allow users to say if the
Automake version is = X, then expand this configure.ac code. I think
that would be general enough (it could use Automake conditionals to
adjust Makefile.am files, it could check for = X and not = X+1 to
enforce exact versions (or we could just provide a general version
compare function) and it could then call AM_INIT_AUTOMAKE with the
appropriate options). Also, it would be explicit enough for the
developer to be conscious about not using this by accident.
However, it would likely allow fool any tools that directly grepped the
configure.ac files for AM_INIT_AUTOMAKE invocations, instead of using
autom4te --language=Autoconf-without-aclocal-m4 --trace=AM_INIT_AUTOMAKE
and even that would probably not give the right answer then (as
aclocal.m4 contents will be needed in order to provide it).
The initial patch below ought to improve the situation for future
Automake versions (but unfortunately not for past ones). With it,
you will be able to write code like
AM_VERSION_PREREQ([1.12],
[# this code assumes Automake 1.12
AM_INIT_AUTOMAKE([foreign fancy-new-option])],
[# this code does not assume 1.12
AM_INIT_AUTOMAKE([foreign])])
Does that look like a viable approach to people?
Of course, just like m4_version_prereq, it violates the Autoconf
principle that you should test the actual feature you would like to use,
rather than some version number. I don't know how to solve that without
another layer of indirection, which would amount to something you
outline in the URL above. (The other rationale why it may not be so bad
here is that luckily, distros seem to provide pretty much plain upstream
Automake these days, without many patches tacked on and features added,
so that a version number actually retains some meaning.)
What you can do in the meantime to have things work well for you with
git Automake (once that provides AM_VERSION_PREREQ) is something like
m4_ifdef([AM_VERSION_PREREQ],
[ use AM_VERSION_PREREQ like above ... ],
[ backward compat code ... ])
and you could even extend the idea to work back to 1.11 by testing for
some macro that was new in 1.11, such as AM_SILENT_RULES or AM_COND_IF.
However, there is a glitch: in case these macros are defined, i.e., the
version is = 1.11, you have to also actually use them in your
configure.ac, so that not only aclocal (who searches in the
.../share/aclocal-X.Y directory by default) finds them as defined, but
also actually includes their definition into the aclocal.m4 file, so
that a subsequent autoconf (who doesn't search .../share/aclocal-X.Y)
finds them defined, too. Clear?
As an unrelated side note, we don't use @defmac to define our macros,
which can cause bugs when used with @dvar on a @-continued definition
line, in the manual. This should be fixed.
Cheers,
Ralf
New macro AM_VERSION_PREREQ.
* m4/amversion.in (_AM_AUTOMAKE_VERSION): New define.
* m4/prereq.m4 (AM_VERSION_PREREQ): New file, new macro,
with code taken from Autoconf's m4_version_prereq.
* tests/prereq.test: New test.
* tests/Makefile.am: Adjust.
* doc/automake.texi (@dvar): New texinfo macro, taken from
Autoconf.
(Public Macros): Document AM_VERSION_PREREQ.
* NEWS: Update.
Based on suggestion from Jim Meyering.
diff --git a/NEWS b/NEWS
index 7e14ed8..fe11327 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
New in 1.11a:
+* Miscellaneous changes:
+
+ - New macro AM_VERSION_PREREQ to allow expanding different code at M4 run
+time based upon the Automake version used.
+
Bugs fixed in 1.11a:
* Bugs introduced by 1.11:
diff --git a/doc/automake.texi b/doc/automake.texi
index b3f4a76..9a489ef 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -15,6 +15,14 @@
@r...@var{\varname\}@r{]}
@end macro
+...@c @dvar(ARG, DEFAULT)
+...@c ---
+...@c The ARG is an optional argument, defaulting to DEFAULT. To be used
+...@c for macro arguments in their documentation (@defmac).
+...@macro dvar{varname, default}
+...@r{[}@var{\varname\} = @samp{\defaul...@r{]}@c
+...@end macro
+
@copying
This manual is for @acronym{GNU} Automake (version @value{VERSION},
@@ -3896,6 +3904,15 @@
Re: Integration of git-based release workflow into make dist
On Fri, Aug 14, 2009 at 12:07:39AM +0100, Roger Leigh wrote: This is a rough outline of what I'd like to do (unless someone beats me to it!) • Add a dist-git option and Makefile target. This will cause $distdir to be injected into git, rather than just calling tar as for other git targets. • This will require some additional options in order to work correctly: · A branch name (the head to append the new tree to) · [optional] Tag name, could be a pattern such as dist/$(VERSION) · [optional] Flag for signing the tag or not . [optional] Template commit message These could all just be variables in the top-level Makefile.am. An initial implementation follows. This works, but it does need further refinement (error checking, for example). And probably review by a git expert. I'm sure other people can make it much nicer, but this hopefully demonstrates the point. The distributed release is put on a distribution branch, and its parents are both the previous release and the current head. i.e. it's a merge of the old distributed release and the current release. This lets you do easy merging of changes between both branches, with a correct history. Regards, Roger GIT_DIST_BRANCH=distrib GIT_DIST_COMMIT_MESSAGE=Distribution of $(PACKAGE) version $(VERSION) GIT_DIST_TAG=true GIT_DIST_TAG_NAME=dist/$(PACKAGE)-$(VERSION) GIT_DIST_TAG_MESSAGE=Distributing $(PACKAGE)-$(VERSION) dist-git: distdir DISTDIR_INDEX=$(distdir).git.idx; \ rm -f $$DISTDIR_INDEX; \ GIT_INDEX_FILE=$$DISTDIR_INDEX GIT_WORK_TREE=$(distdir) git add -A; \ GIT_INDEX_FILE=$$DISTDIR_INDEX TREE=$$(git write-tree); \ rm -f $$DISTDIR_INDEX; \ DIST_HEAD=$$(git show-ref -s HEAD); \ COMMIT_OPTS=-p $$DIST_HEAD; \ DIST_PARENT=$$(git show-ref --heads -s refs/heads/$(GIT_DIST_BRANCH)); \ if [ -n $$DIST_PARENT ]; then \ COMMIT_OPTS=$$COMMIT_OPTS -p $$DIST_PARENT; \ fi; \ COMMIT=$$(echo $(GIT_DIST_COMMIT_MESSAGE) | git commit-tree $$TREE $$COMMIT_OPTS); \ git update-ref refs/heads/$(GIT_DIST_BRANCH) $$COMMIT; \ TAG_OPTS=; \ if [ $(GIT_DIST_TAG) = true ]; then \ TAG_OPTS=$$TAG_OPTS -s; \ fi; \ git tag -m $(GIT_DIST_TAG_MESSAGE) $$TAG_OPTS $(GIT_DIST_TAG_NAME) $$COMMIT; $(am__remove_distdir) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Integration of git-based release workflow into make dist
On Fri, 14 Aug 2009, Roger Leigh wrote: ÿÿ distribute generated release tarball However, the distribute release tarball step is becoming less and less relevant with the advent of git. The release tarball step is always needed since software development is protected by copyright laws so we need a step which is a equivalent to publishing the work. A release branch or tag in a live repository will not be compelling enough in a court of law. No judge or jury would understand it or believe it. Creating a git repository to contain the release and then bundling up so that it can be archived as a new form of tarball would be sufficient as long as it is clearly an act of publishing the work. I do a lot of Debian packaging work, as well as actual software development for Debian. All of this work nowadays occurs in git repositories. For packages of software distributed by third Maintenance for other OSs may be in Subversion, Mercurial, CVS, Perforce, or one of the many other active version control systems. ÿÿ Add a dist-git option and Makefile target. This will cause $distdir to be injected into git, rather than just calling tar as for other git targets. It is easy enough for the Automake user to add targets like dist-git since Automake is extensible. The main problem you will face is how to herd the cats so that they all add a dist-git option that you want for your particular release system. This seems quite hard to accomplish unless your OS distribution can somehow become the clear monopoly player so that the work of others can be ignored and rendered pointless. If this manages to be implemented flexibly and concrete enough to be included in stock Automake, then it should be a requirement to support the many other version control systems as well. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: I think Automake should provide an API to allow users to say if the Automake version is = X, then expand this configure.ac code. I think that would be general enough (it could use Automake conditionals to adjust Makefile.am files, it could check for = X and not = X+1 to enforce exact versions (or we could just provide a general version compare function) and it could then call AM_INIT_AUTOMAKE with the appropriate options). Also, it would be explicit enough for the developer to be conscious about not using this by accident. As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. -- Ben Pfaff http://benpfaff.org
Re: Integration of git-based release workflow into make dist
Hello Roger, * Roger Leigh wrote on Fri, Aug 14, 2009 at 11:40:18AM CEST: An initial implementation follows. This works, but it does need further refinement (error checking, for example). And probably review by a git expert. I'm sure other people can make it much nicer, but this hopefully demonstrates the point. Thanks. Not to sound discouraging, but this seems to be able to cope mostly without any Automake internals (am__remove_distdir is a rather benign issue) nor need special help from Automake. That means it can easily live outside of Automake proper for a while at least, until it is settled and useful for more than a couple of projects or distros, as Bob already noted. You can keep it synchronized across projects easily by putting the code into a fragment.am file and including that into your toplevel Makefile.am, and synchronizing the fragment, no? You could consider submitting this fragment as a gnulib module (where you just place your code into the Makefile.am part of the modules/.. file. Or as part of maint.mk, if the gnulib crowd likes that better. The distributed release is put on a distribution branch, and its parents are both the previous release and the current head. i.e. it's a merge of the old distributed release and the current release. This lets you do easy merging of changes between both branches, with a correct history. Nice idea, thanks! Cheers, Ralf
Re: using color-tests backwards-portably
Hello Ben, * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST: As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. Yes, the idea sounds better. But without also exposing something like AM_SET_OPTION, it would not scale: with the above, you might have exponentially many cases to cater to as user (e.g., 8 for 3 features, if you really want to be fully version-agnostic by ignoring that feature X was introduced after feature Y). One major detail of this idea is that now, aclocal or the macro code supplied with Automake would need to know about the set of options that are supported. It doesn't do so now; only _process_option_list in lib/Automake/Options.pm used at automake run time knows. Also, the set of options isn't just a set of fixed strings, but includes some regexps. I would hate to have to duplicate this functionality in m4, esp. since we definitely also need it at automake run time for those options listed in the AUTOMAKE_OPTIONS Makefile.am variable. Cheers, Ralf
Re: using color-tests backwards-portably
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Ben Pfaff wrote on Fri, Aug 14, 2009 at 06:33:14PM CEST: As an alternative, could Automake provide an API that allows users to say if feature X is supported, then expand this configure.ac code? For example: AM_FEATURE_PREREQ([color-tests], [AM_INIT_AUTOMAKE([foreign color-tests])], [AM_INIT_AUTOMAKE([foreign])]) This seems to me more in keeping with the Autoconf philosophy. Yes, the idea sounds better. But without also exposing something like AM_SET_OPTION, it would not scale: with the above, you might have exponentially many cases to cater to as user (e.g., 8 for 3 features, if you really want to be fully version-agnostic by ignoring that feature X was introduced after feature Y). Well, I suppose that something like this would work: AM_INIT_AUTOMAKE([foreign AM_OPTIONAL_FEATURE([color-tests])]) where AM_OPTIONAL_FEATURE expands to its argument if that feature is supported and to the null string otherwise. (I don't understand the m4 quoting rules well enough to know whether I have the quoting right here.) One major detail of this idea is that now, aclocal or the macro code supplied with Automake would need to know about the set of options that are supported. It doesn't do so now; only _process_option_list in lib/Automake/Options.pm used at automake run time knows. Also, the set of options isn't just a set of fixed strings, but includes some regexps. OK. -- Ben Pfaff http://benpfaff.org
