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: 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: 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
using color-tests backwards-portably
Hi Ralf, I'd like to use automake-1.11's color-tests option in libguestfs -- and more importantly, parallel-tests, but we may have a build-from-clone requirement on systems with automake older than 1.11. On those systems, it's fine to ignore or disable these two unsupported options. 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 know I could roll my own via check.mk, like what coreutils used prior to automake-1.11, but would rather use automake's own support for those options, when possible. ] Thanks, Jim
