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
