Re: unoptimized autoconf generated code
According to Ralf Wildenhues on 3/2/2010 10:53 PM: Actually, it's a doc bug. This is not valid shell variable assignment: `echo $foo`=yes So this patch is going in now, while I spend more time fixing the actual code changes. Thanks. Sticking an eval in front of any AS_TR_SH is going to be pretty fragile though, and I'm not really sure whether, at the time this example was added, the eval wasn't part of the AS_TR_SH expansion. AS_TR_SH has never included eval. It's just that most use cases hide the need for eval from the user (that is, you are most likely to need AS_TR_SH in the context of AS_VAR_*, but those API use AS_LITERAL_IF under the hood to decide when an eval is necessary). Fortunately, one of the guarantees of AS_TR_SH is that the output is a valid shell variable (no metacharacters, no issues from a second level of expansion, ...), so it is one case where eval gotchas are less likely to happen, provided that the rest of the line containing the AS_TR_SH is careful (AS_ESCAPE comes in handy). At any rate, I finally tracked down why I was getting testsuite failures with patch 2/3; here's the updated version that passes the testsuite (again, 1/3 and 3/3 are unchanged). It also turned out rather large, so I'm still thinking about splitting it into two parts; first the introduction of AS_LITERAL_IF_W (or a better name, if anyone has a suggestion) and cleanups outside of lib/m4sugar, and second touching only lib/m4sugar to implement the optional argument. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org From cd9b7c590e884c33b060f56579414b207ec83a86 Mon Sep 17 00:00:00 2001 From: Eric Blake ebl...@redhat.com Date: Sat, 27 Feb 2010 10:39:31 -0700 Subject: [PATCH] Add optional argument to AS_LITERAL_IF. * lib/m4sugar/m4sh.m4 (_AS_LITERAL_IF): Rewrite to generate macro name, without using m4_cond. Allow more control over whitespace. (_AS_LITERAL_IF_, _AS_LITERAL_IF_YES, _AS_LITERAL_IF_NO): New helpers. (AS_LITERAL_IF, _AS_TR_SH, _AS_TR_CPP, _AS_VAR_PUSHDEF): Adjust callers. (AS_LITERAL_IF_W): New macro to keep old semantics. * lib/autoconf/types.m4 (AC_CHECK_ALIGNOF): Relax restrictions on invalid bytes, since this allows inline struct layouts. (_AC_CHECK_ALIGNOF): New helper macro. (AC_CHECK_SIZEOF, AC_CHECK_MEMBER): Use new macro to preserve handling of space. * lib/autoconf/general.m4 (_AC_INIT_PACKAGE): Likewise. (_AC_DEFINE_Q): No need to use AS_LITERAL_IF. * tests/m4sh.at (AS@t...@_literal_if): Update test. * doc/autoconf.texi (Polymorphic Variables) AS_LITERAL_IF: Tighten specification and document extra parameter. * NEWS: Mention the change. Signed-off-by: Eric Blake ebl...@redhat.com --- ChangeLog | 22 +++- NEWS|6 +++ doc/autoconf.texi | 45 ++- lib/autoconf/general.m4 |6 ++-- lib/autoconf/types.m4 | 26 +- lib/m4sugar/m4sh.m4 | 88 +++ tests/m4sh.at | 28 +++ 7 files changed, 169 insertions(+), 52 deletions(-) diff --git a/ChangeLog b/ChangeLog index 4b38b7a..679c64a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,24 @@ -2010-03-02 Eric Blake ebl...@redhat.com +2010-03-03 Eric Blake ebl...@redhat.com + + Add optional argument to AS_LITERAL_IF. + * lib/m4sugar/m4sh.m4 (_AS_LITERAL_IF): Rewrite to generate macro + name, without using m4_cond. Allow more control over whitespace. + (_AS_LITERAL_IF_, _AS_LITERAL_IF_YES, _AS_LITERAL_IF_NO): New + helpers. + (AS_LITERAL_IF, _AS_TR_SH, _AS_TR_CPP, _AS_VAR_PUSHDEF): Adjust + callers. + (AS_LITERAL_IF_W): New macro to keep old semantics. + * lib/autoconf/types.m4 (AC_CHECK_ALIGNOF): Relax restrictions on + invalid bytes, since this allows inline struct layouts. + (_AC_CHECK_ALIGNOF): New helper macro. + (AC_CHECK_SIZEOF, AC_CHECK_MEMBER): Use new macro to preserve + handling of space. + * lib/autoconf/general.m4 (_AC_INIT_PACKAGE): Likewise. + (_AC_DEFINE_Q): No need to use AS_LITERAL_IF. + * tests/m4sh.at (AS@t...@_literal_if): Update test. + * doc/autoconf.texi (Polymorphic Variables) AS_LITERAL_IF: + Tighten specification and document extra parameter. + * NEWS: Mention the change. Optimize AS_BOX. * lib/m4sugar/m4sh.m4 (AS_BOX): Use less m4 time. diff --git a/NEWS b/NEWS index c11d3a1..d273126 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,12 @@ GNU Autoconf NEWS - User visible changes. ** The following macros are now documented: AS_BOX +** The AS_LITERAL_IF macro no longer accepts whitespace as literals, in + order to support the addition of an optional parameter to reduce + script size for some cases of indirect variable references. The + older semantics of ignoring space, tab, and newline is exposed + via the new macro AS_LITERAL_IF_W. + * Major changes in
Autoconf Macro Archive URL has changed.
Hi autoconfers,
The URL to the Autoconf Macro Archive has changed as it now is a
official GNU package. The attached patch reflect that change.
http://www.gnu.org/software/autoconf-archive/
Thanks,
Peter
diff --git a/ChangeLog b/ChangeLog
index 5aae86c..bc0adcf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-03-03 Peter Johansson troj...@gmail.com
+
+ * doc/autoconf.texi (Introduction): The Autoconf Macro
+ Archive is officially `GNU'. Update URL.
+
2010-03-02 Eric Blake ebl...@redhat.com
Fix shell code in AS_TR_SH documentation.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 8fca9ae..b67a749 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -793,7 +793,7 @@ Because of its mission, the Autoconf package itself
includes only a set of often-used
macros that have already demonstrated their usefulness. Nevertheless,
if you wish to share your macros, or find existing ones, see the
-...@uref{http://@/autoconf-archive.cryp.to/, Autoconf Macro
+...@uref{http://@/www.gnu.org/software/autoconf-archive/, Autoconf Macro
Archive}, which is kindly run by @email{simons@@cryp.to,
Peter Simons}.
AC_CHECK_FUNCS and gcc with -Werror
Hi,
in configure.in I have:
AC_CHECK_FUNCS(printf)
together with some
---8===
AC_DEFUN([IC_ENABLE_ERRORS],[
AC_ARG_ENABLE(errors,
[ --enable-errors[=ARG] Enable error mode
(warnings are errors) [ARG=no]],
if test x$enable_errors = xyes ; then
case $CC in
dnl Just in case someone would have a non-gcc thingcc, don't match *gcc
gcc|*-gcc)
CFLAGS=$CFLAGS -Werror;
;;
===8---
In config.log then:
configure:11204: gcc -o conftest -Wall -Wmissing-prototypes
-fstrict-aliasing -D_GNU_SOURCE -ansi -ggdb -D_REENTRANT -Werror
-ggdb conftest
.c -lpthread 5
cc1: warnings being treated as errors
conftest.c:67: warning: conflicting types for built-in function 'printf'
what to do best here?
oki,
Steffen
---8===
configure:11204: gcc -o conftest -Wall -Wmissing-prototypes
-fstrict-aliasing -D_GNU_SOURCE -ansi -ggdb -D_REENTRANT -Werror
-ggdb conftest
.c -lpthread 5
cc1: warnings being treated as errors
conftest.c:67: warning: conflicting types for built-in function 'printf'
configure:11204: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_XXX
| #define PACKAGE_XX
| #define PACKAGE_XX
| #define PACKAGE_X
| #define PACKAGE_
| #define PACKAGE_XX
| #define PACKAGE XXX
| #define VERSION XXX
| #define linux 1
| #define unix 1
| #define DEBUG 1
| #define ENABLE_LOCATED_MESSAGES 1
| #define CBASE_GENSRC_ERROR_NAMES 1
| #define CLOG_ENABLE_LOW_LEVEL_MESSAGES 1
| #define ENABLE_MALLOC_TRACE 1
| #define ENABLE_UNITTESTS 1
| #define HAVE_CONFIG_SYS_H 1
| #define ENABLE_CCSLOT_LOADER 1
| #define THREADSAFE 1
| #define HAVE_LIBPTHREAD 1
| #define HAVE_PTHREAD_H 1
| #define ENABLE_MULTITHREAD 1
| #define _FILE_OFFSET_BITS 64
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_ERRNO_H 1
| #define HAVE_TIME_H 1
| #define HAVE_CTYPE_H 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_TCSETATTR 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SELECT 1
| #define HAVE_LOCALTIME_R 1
| /* end confdefs.h. */
| /* Define printf to an innocuous variant, in case limits.h declares printf.
|For example, HP-UX 11i limits.h declares gettimeofday. */
| #define printf innocuous_printf
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char printf (); below.
| Prefer limits.h to assert.h if __STDC__ is defined, since
| limits.h exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include limits.h
| #else
| # include assert.h
| #endif
|
| #undef printf
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern C
| #endif
| char printf ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_printf || defined __stub___printf
| choke me
| #endif
|
| int
| main ()
| {
| return printf ();
| ;
| return 0;
| }
configure:11204: result: no
configure:11215: checking for psyPeripheralResultWait
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On 03/03/2010 11:52 AM, Steffen Dettmer wrote: Hi, in configure.in I have: AC_CHECK_FUNCS(printf) together with some ---8=== AC_DEFUN([IC_ENABLE_ERRORS],[ AC_ARG_ENABLE(errors, [ --enable-errors[=ARG] Enable error mode (warnings are errors) [ARG=no]], if test x$enable_errors = xyes ; then case $CC in dnl Just in case someone would have a non-gcc thingcc, don't match *gcc gcc|*-gcc) CFLAGS=$CFLAGS -Werror; ;; ===8--- In config.log then: configure:11204: gcc -o conftest -Wall -Wmissing-prototypes -fstrict-aliasing -D_GNU_SOURCE -ansi -ggdb -D_REENTRANT -Werror -ggdb conftest .c -lpthread5 cc1: warnings being treated as errors conftest.c:67: warning: conflicting types for built-in function 'printf' what to do best here? Not using -Werror Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to handle new subdirectories?
Hi, thanks again for your quick and helpful reply. On Wed, Mar 3, 2010 at 7:33 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Steffen Dettmer wrote on Tue, Mar 02, 2010 at 04:25:50PM CET: For new subdirectories with new Makefile.am autoconf/automake fails because Makefile.in seems not to be created automatically, I'm not sure I understand. The normal way to add a new directory is to add AC_CONFIG_FILES([dir/Makefile]) (or add to AC_OUTPUT, seems with AC_OUTPUT, AC_CONFIG_FILES won't work) to configure.ac, write dir/Makefile.am, and add something like SUBDIRS += dir to a Makefile.am above dir (or sub/../dir if more than one level above). Then, unless you have maintainer-mode turned off, just run 'make'.[1] ohh, indeed. It seems I tested wrongly and that I had a different problem. Seems I missed an important warning in the heaps of warning I got :( WARNING: `aclocal-1.11' is missing on your system which seems to be caused because I tried to use automake without `make install' it, which seems not to be allowed. Sorry for the inconvenience. It just works correctly. Great! So if we would make the upgrade we could drop workarounds, good :) 2) new autoconf directories: I'd like to understand your use case in (1) first. I retested this as well but still don't see it working. So probably I made another mistake :) I have a new dir with dir/configure.in and added it to ./configure.in's AC_CONFIG_SUBDIRS([dir]). In Makefile.am I have subdi...@subdirs@ admin make then runs aclocal, automake, autoconf and ./config.status --recheck, but only in `.' not in `dir'. Then it recurses SUBDIRS, finally dir and aborts: make[1]: *** No rule to make target `all'. Stop. in `dir' there is no configure and no Makefile. oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
According to Ralf Corsepius on 3/3/2010 4:04 AM: On 03/03/2010 11:52 AM, Steffen Dettmer wrote: Hi, in configure.in I have: AC_CHECK_FUNCS(printf) C89 guarantees the existence of printf - this particular use of AC_CHECK_FUNCS is most likely unnecessary for any modern machine, unless your goal is to port to an embedded system that doesn't provide all of C89. cc1: warnings being treated as errors conftest.c:67: warning: conflicting types for built-in function 'printf' what to do best here? Not using -Werror That's been the standard advice for years now. Don't do something if it hurts. -Werror is a can of worms - there is NO way to silence all possible warnings for all possible compilers. It's great on a per-compiler build (for example, coreutils provides --enable-gcc-warnings, which conditionally adds -Werror to CFLAGS if the compiler spuports it), but only for the program itself, and not for the duration of the configure run. Meanwhile, there is a patch on the table to teach autoconf 2.66 how to recognize and work around -Werror coupled with gcc; I hope to finish reviewing and apply it soon. http://lists.gnu.org/archive/html/bug-autoconf/2010-02/msg00040.html -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to handle new subdirectories?
According to Steffen Dettmer on 3/3/2010 4:31 AM: I have a new dir with dir/configure.in and added it to ./configure.in's AC_CONFIG_SUBDIRS([dir]). You may want to consider renaming all of those to configure.ac instead. That has been the recommended practice for several years now. In Makefile.am I have subdi...@subdirs@ admin Have you tried automake conditionals, along the lines of: SUBDIRS= if BUILD_SUBDIR SUBDIRS += subdir endif SUBDIRS += admin so that you are passing literal subdir names to SUBDIRS rather than values substituted at configure time? The automake manual has a node on conditional subdirectories. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to handle new subdirectories?
Hi, thanks for your quick reply. On Wed, Mar 3, 2010 at 1:54 PM, Eric Blake ebl...@redhat.com wrote: According to Steffen Dettmer on 3/3/2010 4:31 AM: I have a new dir with dir/configure.in and added it to ./configure.in's AC_CONFIG_SUBDIRS([dir]). You may want to consider renaming all of those to configure.ac instead. That has been the recommended practice for several years now. Ohh, does this have an effect? We also have .m4 files included. I feel `.in' for input files more straightforward and CVS does not handle renaming files. In Makefile.am I have subdi...@subdirs@ admin so that you are passing literal subdir names to SUBDIRS rather than values substituted at configure time? The automake manual has a node on conditional subdirectories. Ohh no, sorry, they are not conditional. The subdi...@subdirs@ is just there to avoid the redundancy to AC_CONFIG_SUBDIRS (in almost all our cases, SUBDIRS is the same as AC_CONFIG_SUBDIRS plus admin directory). I think using @subdirs@ cannot be the problem because in the new directory not even configure is created from configure.in when running make. The problem is when a new package (let's say a lib) is added to the super-package, the super-package configure has a new subdir to configure recursively. Maybe I tell the high-level-problem with other words: After cvs update, when a new sub-package was added and AC_CONFIG_SUBDIRS was extended, make fails. So each user must pre-conf (autoreconf or so) the srcdir and re-configure each builddir (uncomfortable and takes much time and touches all config.h) and then re-make everything (takes much time again). Is there some trick / way to improve on that? Our current workaround has recheck-recursive: @echo In directory `pwd`: ../../configure `cat .config-opts` in toplevel Makefile (to be run by `for d in * ... make -C $d recheck'), which works automatically (but still consumes much time, but can be run in background). oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On Wed, Mar 3, 2010 at 1:47 PM, Eric Blake ebl...@redhat.com wrote: According to Ralf Corsepius on 3/3/2010 4:04 AM: On 03/03/2010 11:52 AM, Steffen Dettmer wrote: Hi, in configure.in I have: AC_CHECK_FUNCS(printf) C89 guarantees the existence of printf - this particular use of AC_CHECK_FUNCS is most likely unnecessary for any modern machine, unless your goal is to port to an embedded system that doesn't provide all of C89. Unfortunately we cannot rely on C89. (a platform without a function actually is the easy case; the difficult case is when a platform is able to link a function which must not be called because it just crashes because of bad library retargeting) cc1: warnings being treated as errors conftest.c:67: warning: conflicting types for built-in function 'printf' what to do best here? Not using -Werror That's been the standard advice for years now. Do I understand correctly that it is generally adviced to not use the option -Werror? Do you have some link? In my case, most Development Rules require that sources compile without warnings. It seems that across the team less warnings get accidently checked in when using -Werror/-WX (our other compilers have no such option) or what the compilers support to abort on warnings, so it was decided to build some software with that option. Don't do something if it hurts. mmm... (I think the idea is to make a warning hurting to ensure that it is fixed instantly and cannot be overseen / forgotten). -Werror is a can of worms - there is NO way to silence all possible warnings for all possible compilers. It's great on a per-compiler build (for example, coreutils provides --enable-gcc-warnings, which conditionally adds -Werror to CFLAGS if the compiler spuports it), but only for the program itself, and not for the duration of the configure run. Yes, inside configure -Werror isn't needed but for compiling all the programs source files. How to add it for the program but not for the configure run? Via libxyz_a_CFLAGS of all libs? Meanwhile, there is a patch on the table to teach autoconf 2.66 how to recognize and work around -Werror coupled with gcc; I hope to finish reviewing and apply it soon. http://lists.gnu.org/archive/html/bug-autoconf/2010-02/msg00040.html ohh sounds promising :) oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
According to Steffen Dettmer on 3/3/2010 6:33 AM: what to do best here? Not using -Werror That's been the standard advice for years now. Do I understand correctly that it is generally adviced to not use the option -Werror? Not quite. The advice is to not mix -Werror and configure. Post-configure, you can use -Werror to your heart's content, and I do it all the time in packages that I maintain. And it is even possible to let configure check whether -Werror works, and if so, automatically add it to CFLAGS. It's just that configure checks themselves are not guaranteed to be warning-free, so converting warnings to errors during configure is a recipe for disaster. In other words, the advice is that you shouldn't use './configure CFLAGS=-Werror'. Don't do something if it hurts. mmm... (I think the idea is to make a warning hurting to ensure that it is fixed instantly and cannot be overseen / forgotten). The problem is that no one has submitted a patch to make configure and -Werror try to play nicely, until last month; and even then, it is not the easiest thing in the world to do. Yes, inside configure -Werror isn't needed but for compiling all the programs source files. How to add it for the program but not for the configure run? Via libxyz_a_CFLAGS of all libs? That's one way. Or even via CFLAGS itself. It's just that you have to be careful that the CFLAGS are different during the configure run than during make in that case. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On 03/03/2010 02:44 PM, Eric Blake wrote: According to Steffen Dettmer on 3/3/2010 6:33 AM: what to do best here? Not using -Werror That's been the standard advice for years now. Do I understand correctly that it is generally adviced to not use the option -Werror? Not quite. The advice is to not mix -Werror and configure. Post-configure, you can use -Werror to your heart's content, and I do it all the time in packages that I maintain. And it is even possible to let configure check whether -Werror works, and if so, automatically add it to CFLAGS. It's just that configure checks themselves are not guaranteed to be warning-free, so converting warnings to errors during configure is a recipe for disaster. In other words, the advice is that you shouldn't use './configure CFLAGS=-Werror'. Another aspect is -Wall and -Werror are moving (and architecture dependent) targets. I.e. the number of warnings GCC will issue changes over time, triggering different kind of warnings. I.e. when using -Werror a configure script will fail for different kinds of reasons at different places depending on your toolchain. I.e. the best your Development Rules will be able to achieve is warning free compilation in a very narrowly pre-defined setup, with a well defined toolchain. Don't do something if it hurts. mmm... (I think the idea is to make a warning hurting to ensure that it is fixed instantly and cannot be overseen / forgotten). The problem is that no one has submitted a patch to make configure and -Werror try to play nicely, until last month; and even then, it is not the easiest thing in the world to do. There is another aspect: There exist configure-checks which rely on switching on/off -Werror. I haven't checked how this recent submission co-exists with such kind of configure-checks. Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On Wed, Mar 3, 2010 at 2:44 PM, Eric Blake ebl...@redhat.com wrote: According to Steffen Dettmer on 3/3/2010 6:33 AM: Do I understand correctly that it is generally adviced to not use the option -Werror? Not quite. The advice is to not mix -Werror and configure. ahh ok, this is fine! There is no need to have -Werror during configure. So it seems again we just do the things wrongly :) But how to do it correctly? Post-configure, you can use -Werror to your heart's content, and I do it all the time in packages that I maintain. I'm not sure if I get this... How do I use -Werror or -WX post-configure correctly? And it is even possible to let configure check whether -Werror works, and if so, automatically add it to CFLAGS. but CFLAGS are used by AC_CHECK_FUNCS? (I think this is exactly my problem. my configure adds -Werror/-WX automatically to CFLAGS). It's just that configure checks themselves are not guaranteed to be warning-free, so converting warnings to errors during configure is a recipe for disaster. In other words, the advice is that you shouldn't use './configure CFLAGS=-Werror'. we use `./configure --enable-errors' (yes, the option name isn't the best possible) which internally appends -Werror/-WX to CFLAGS. mmm... (I think the idea is to make a warning hurting to ensure that it is fixed instantly and cannot be overseen / forgotten). The problem is that no one has submitted a patch to make configure and -Werror try to play nicely, until last month; and even then, it is not the easiest thing in the world to do. I'm sorry, I didn't express well what we want. We do not need/want -Werror inside configure. Just inside make. I'm afraid again I just fail to see the obvious and it is very easy to do? Yes, inside configure -Werror isn't needed but for compiling all the programs source files. How to add it for the program but not for the configure run? Via libxyz_a_CFLAGS of all libs? That's one way. Or even via CFLAGS itself. It's just that you have to be careful that the CFLAGS are different during the configure run than during make in that case. We now have in configure.in (or actually an included .m4 file) `CFLAGS=$CFLAGS -Werror;' and `CFLAGS=$CFLAGS -WX'. Is this `via CFLAGS itself'? sorry for my silly questions but I just don't get it... oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On Wed, Mar 3, 2010 at 3:00 PM, Ralf Corsepius rc040...@freenet.de wrote: Another aspect is -Wall and -Werror are moving (and architecture dependent) targets. I.e. the number of warnings GCC will issue changes over time, triggering different kind of warnings. Yes, new compiler versions or includes (SDK updates) often lead to new warnings. I.e. the best your Development Rules will be able to achieve is warning free compilation in a very narrowly pre-defined setup, with a well defined toolchain. Yes, you are right of course, those rules do not apply to all software and toolchains but to the we release as binary builds. The problem is that no one has submitted a patch to make configure and -Werror try to play nicely, until last month; and even then, it is not the easiest thing in the world to do. There is another aspect: There exist configure-checks which rely on switching on/off -Werror. I haven't checked how this recent submission co-exists with such kind of configure-checks. ohh sorry, I expressd myself wrongly. As I already wrote Eric, for us it does not matter how -Werror is switched internally, only that it is set within Makefile. oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On 03/03/2010 03:27 PM, Steffen Dettmer wrote: On Wed, Mar 3, 2010 at 2:44 PM, Eric Blakeebl...@redhat.com wrote: According to Steffen Dettmer on 3/3/2010 6:33 AM: Do I understand correctly that it is generally adviced to not use the option -Werror? Not quite. The advice is to not mix -Werror and configure. ahh ok, this is fine! There is no need to have -Werror during configure. So it seems again we just do the things wrongly :) But how to do it correctly? Post-configure, you can use -Werror to your heart's content, and I do it all the time in packages that I maintain. I'm not sure if I get this... How do I use -Werror or -WX post-configure correctly? Several ways: a) Override CFLAGS at make time: ./configure CFLAGS=cflags make CFLAGS=cflags -Werror This is what I would do - It doesn't clutter the autotool-files with GCC-proprietary -Werror handling and is appropriate for development purposes. b) Implement it as a conditional AC_SUBST, i.e. something similar to AC_ARG_ENABLE([werror], ... /* if gcc */ CFLAGS_WERROR=-Werror ... /* if other compiler */ CFLAGS_WERROR=whatever ... ]) AC_SUBST([CFLAGS_WERROR]) accompanied by something similar to this in your Makefile.in's CFLAGS = @CFLAGS@ @CFLAGS_WERROR@ rsp. (in case of using automake) AM_CFLAGS = @CFLAGS_WERROR@ I would not want to use this approach. Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
According to Steffen Dettmer on 3/3/2010 7:27 AM:
I'm sorry, I didn't express well what we want. We do not
need/want -Werror inside configure. Just inside make.
I'm afraid again I just fail to see the obvious and it is very
easy to do?
Yes. Here's how m4 does it. It uses the gl_WARN_ADD macro from the
gnulib module manywarnings; but if you choose not to use gnulib, it is a
simple enough macro that you can probably just inline it directly into
configure.ac:
# gl_WARN_ADD(PARAMETER, [VARIABLE = WARN_CFLAGS])
#
# Adds parameter to WARN_CFLAGS if the compiler supports it. For example,
# gl_WARN_ADD([-Wparentheses]).
AC_DEFUN([gl_WARN_ADD],
[AS_VAR_PUSHDEF([gl_Warn], [gl_cv_warn_$1])dnl
AC_CACHE_CHECK([whether compiler handles $1], [gl_Warn], [
save_CPPFLAGS=$CPPFLAGS
CPPFLAGS=${CPPFLAGS} $1
AC_PREPROC_IFELSE([AC_LANG_PROGRAM([])],
[AS_VAR_SET([gl_Warn], [yes])],
[AS_VAR_SET([gl_Warn], [no])])
CPPFLAGS=$save_CPPFLAGS
])
AS_VAR_PUSHDEF([gl_Flags], m4_if([$2], [], [[WARN_CFLAGS]], [[$2]]))dnl
AS_VAR_IF([gl_Warn], [yes], [gl_AS_VAR_APPEND([gl_Flags], [ $1])])
AS_VAR_POPDEF([gl_Flags])dnl
AS_VAR_POPDEF([gl_Warn])dnl
m4_ifval([$2], [AS_LITERAL_IF([$2], [AC_SUBST([$2])], [])])dnl
])
Then in configure.ac, you give the user the option to request extra
compiler flags, and create an AC_SUBST variable containing the result of
the supported flags:
AC_ARG_ENABLE([gcc-warnings],
[AS_HELP_STRING([--enable-gcc-warnings],
[turn on lots of GCC warnings (for developers)])],
[case $enableval in
yes|no) ;;
*) AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
esac
gl_gcc_warnings=$enableval],
[gl_gcc_warnings=no]
)
if test $gl_gcc_warnings = yes; then
gl_WARN_ADD([-Werror], [WERROR_CFLAGS])
AC_SUBST([WERROR_CFLAGS])
# ... more here, for selecting particular -W warnings
fi
Finally, in Makefile.am, you use those flags. That way, CFLAGS was
unchanged during configure (except temporarily, during gl_WARN_ADD, when
sniffing whether the flag works), but make gets the benefit of the flag:
AM_CFLAGS = $(WERROR_CFLAGS)
We now have in configure.in (or actually an included .m4 file)
`CFLAGS=$CFLAGS -Werror;'
That's where you are going wrong. The recommended approach is to modify
CFLAGS in the Makefile, using an AC_SUBST, rather than hard-coding the
modification into configure.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On Wed, 3 Mar 2010, Steffen Dettmer wrote: ohh sorry, I expressd myself wrongly. As I already wrote Eric, for us it does not matter how -Werror is switched internally, only that it is set within Makefile. Hi Steffen, (1) one way to do that is to append -Werror to CFLAGS after doing all sorts of tests in configure.ac. The tests always use the current value of CFLAGS. (2) as noted by others, appending a mandatory(?) flag to CFLAGS is a bad idea (and contradicts the GNU coding standards). CFLAGS is one of the variables passed from configure to Makefile that can also be specified on the Make command line, i.e., `is reserved for the user'. Regards Peter Breitenlohner p...@mppmu.mpg.de ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
AS assembler variable
How does the variable AS get set for the assembler? ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AS assembler variable
According to NightStrike on 3/3/2010 11:53 AM: How does the variable AS get set for the assembler? Autoconf doesn't mess with $AS. But libtool does (libltdl/m4/ltoptions.m4); maybe you should ask there if you need more help. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Autoupdate and AC_ERROR
I ran autoupdate on a configure.ac that yielded the following diff: - [AC_ERROR([Invalid option: $enable_sdk. Please choose one of ddk, directx, or all.])]) + [AC_MSG_ERROR(Invalid option: $enable_sdk. Please choose one of ddk, directx, or all.)]) The intent of the change is fine, but how autoupdate went about it is not. It messed up the nesting of ] and ), as you can see. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Autoupdate and AC_ERROR
On Wed, Mar 3, 2010 at 2:08 PM, NightStrike nightstr...@gmail.com wrote: I ran autoupdate on a configure.ac that yielded the following diff: - [AC_ERROR([Invalid option: $enable_sdk. Please choose one of ddk, directx, or all.])]) + [AC_MSG_ERROR(Invalid option: $enable_sdk. Please choose one of ddk, directx, or all.)]) The intent of the change is fine, but how autoupdate went about it is not. It messed up the nesting of ] and ), as you can see. s/nesting/quoting/ The error message was quoted in [] before the change, and not after. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AS assembler variable
On Wed, Mar 3, 2010 at 2:02 PM, Eric Blake ebl...@redhat.com wrote: According to NightStrike on 3/3/2010 11:53 AM: How does the variable AS get set for the assembler? Autoconf doesn't mess with $AS. But libtool does (libltdl/m4/ltoptions.m4); maybe you should ask there if you need more help. I'm trying to remove libtool support. I'm guessing it comes from AM_PROG_AS, so I guess I need to ask automake. This might fall into another category of not using the $host variant of a tool. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
Peter Breitenlohner p...@mppmu.mpg.de writes: On Wed, 3 Mar 2010, Steffen Dettmer wrote: ohh sorry, I expressd myself wrongly. As I already wrote Eric, for us it does not matter how -Werror is switched internally, only that it is set within Makefile. (1) one way to do that is to append -Werror to CFLAGS after doing all sorts of tests in configure.ac. The tests always use the current value of CFLAGS. (2) as noted by others, appending a mandatory(?) flag to CFLAGS is a bad idea (and contradicts the GNU coding standards). CFLAGS is one of the variables passed from configure to Makefile that can also be specified on the Make command line, i.e., `is reserved for the user'. What I do for my projects is add a separate warnings target to my Automake Makefile.am: # A set of flags for warnings. Add -O because gcc won't find some warnings # without optimization turned on, and add -DDEBUG=1 so we'll also compile all # debugging code and test it. WARNINGS = -g -O -DDEBUG=1 -Wall -W -Wendif-labels -Wpointer-arith \ -Wbad-function-cast -Wwrite-strings -Wstrict-prototypes \ -Wmissing-prototypes -Wnested-externs -Werror warnings: $(MAKE) V=0 CFLAGS='$(WARNINGS)' $(MAKE) V=0 CFLAGS='$(WARNINGS)' $(check_PROGRAMS) The coding style standard then requires that all code compile with make warnings before being committed, but that way the distributed code to the end user doesn't enable aggressive warnings and -Werror, since normally new warnings on the end-user system are better skipped than used to prompt a build failure. Overriding CFLAGS as this target does is not good practice for any target that would be used by the end user, since the user may have set CFLAGS to something else, but it's fine for targets like this that are generally only run by developers. This approach also lets me use gcc-specific warning flags since I know the developers will be using gcc, as opposed to end users who may be using a wide variety of other compilers. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AS assembler variable
* Eric Blake wrote on Wed, Mar 03, 2010 at 08:02:10PM CET: According to NightStrike on 3/3/2010 11:53 AM: How does the variable AS get set for the assembler? Autoconf doesn't mess with $AS. But libtool does (libltdl/m4/ltoptions.m4); maybe you should ask there if you need more help. It is indeed libtool, but the setting is only done with option win32-dll enabled, and even then only on w32 systems. It could probably be removed, because current libtool does not ever use it. If you need as, put AC_CHECK_TOOL([AS], [as], [false]) before LT_INIT. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On Wed, Mar 3, 2010 at 3:59 PM, Eric Blake ebl...@redhat.com wrote:
I'm afraid again I just fail to see the obvious and it is very
easy to do?
Yes. Here's how m4 does it. It uses the gl_WARN_ADD macro from the
gnulib module manywarnings; but if you choose not to use gnulib, it is a
simple enough macro that you can probably just inline it directly into
configure.ac:
# gl_WARN_ADD(PARAMETER, [VARIABLE = WARN_CFLAGS])
(ohh and this piece of M4-language-magic you call `very easy'...
will I ever be able to understand a bit of it uhh-ohh...)
#
# Adds parameter to WARN_CFLAGS if the compiler supports it. For example,
# gl_WARN_ADD([-Wparentheses]).
AC_DEFUN([gl_WARN_ADD],
(If I understand correctly, this macro checks if the compiler
still runs when the flag is given.)
Then in configure.ac, you give the user the option to request extra
compiler flags, and create an AC_SUBST variable containing the result of
the supported flags:
AC_ARG_ENABLE([gcc-warnings],
ahh, you already wrote but I just notice now, it is gcc-option.
So instead of --enable-errors we could use --enable-gcc-errors
and --enable-cl-errors.
Finally, in Makefile.am, you use those flags. That way, CFLAGS was
unchanged during configure (except temporarily, during gl_WARN_ADD, when
sniffing whether the flag works), but make gets the benefit of the flag:
AM_CFLAGS = $(WERROR_CFLAGS)
ahh ok this way.
Before I change my 352 Makefile.am's:
- Can this do harm (e.g. in makefiles for packages without C
sources or so)?
- Can I simply append `AM_CFLAGS += $(WERROR_CFLAGS)' to each
Makefile.am and be done?
- should I better use something like `-include warnings.mak' or
alike to be more flexible in case I'll need it later?
- Alternatively, by accident, ts there some way to tell configure
something like: right just before writing config.status, set
`CFLAGS=$CFLAGS\ $WERROR_CFLAGS' or so?
As Peter suggests?
- Instead of changing 352 Makefile.am's, should I change 42
configure.{in,ac} to have a line like
CFLAGS=$CFLAGS\ $WERROR_CFLAGS
right before AC_OUTPUT? Wouldn't this work, too? But as far as
I know the order of macros/statements in configure.in does not
mean that the actions are really executed in the order they
appear...
Would this be an automatic way of what Peter suggests?
We now have in configure.in (or actually an included .m4
file) `CFLAGS=$CFLAGS -Werror;'
That's where you are going wrong. The recommended approach is
to modify CFLAGS in the Makefile, using an AC_SUBST, rather
than hard-coding the modification into configure.
ohh I though configure should configure the compiler flags?
We do not want that developers have to know about compiler flags
(i.e. they should not need to run make CFLAGS=longListOfStrangeThings),
especially when they cross-compile just to check for warnings
with compilers for platforms they don't use.
oki,
Steffen
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
On Wed, Mar 3, 2010 at 8:41 PM, Russ Allbery r...@stanford.edu wrote: WARNINGS = warnings: $(MAKE) V=0 CFLAGS='$(WARNINGS)' $(MAKE) V=0 CFLAGS='$(WARNINGS)' $(check_PROGRAMS) yes, also a nice idea :) The coding style standard then requires that all code compile with make warnings before being committed, so the users that do not fix warnings during normal compilation do not `forget' to run make warnings and then fix all the errors? I would guess the users that forget to fix warnings are the same that forget to run `make warning' :) This approach also lets me use gcc-specific warning flags since I know the developers will be using gcc, as opposed to end users who may be using a wide variety of other compilers. Isn't there a generic way? Configure has some `checking whether we are using the gcc compiler', right? So why not adding some `checking whether we are using the MS compiler'? (we have some if test $CC=CL.EXE check, but better would to run it and check the output text / version number to find out what it is, also to support options that have been renamed across the versions / years) oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
Hi *, hey guys, thanks so much for all the helpful replies and the patience with me. You just rock, great, thank you. have a good night (or day :)) everyone! oki, Steffen ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
Steffen Dettmer steffen.dett...@googlemail.com writes: so the users that do not fix warnings during normal compilation do not `forget' to run make warnings and then fix all the errors? I would guess the users that forget to fix warnings are the same that forget to run `make warning' :) Well, you also have the same problem with developers who don't remember to run the test suite. :) The best solution, in my experience, is to have a separate build host that periodically attempts to build the current trunk, using make warnings, and then runs the test suite and complains if it fails. Isn't there a generic way? Configure has some `checking whether we are using the gcc compiler', right? So why not adding some `checking whether we are using the MS compiler'? (we have some if test $CC=CL.EXE check, but better would to run it and check the output text / version number to find out what it is, also to support options that have been renamed across the versions / years) You can, and that would be more flexible, but it would also require researching and maintaining warning flags for whatever compilers you want to support. I haven't found that to be a particularly useful way to spend time, but then I'm mostly working on open source software where building with vendor compilers isn't that common. If you specifically want to support a particular vendor compiler, it may be worthwhile to do something more complex to select warning flags for that compiler as well. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
According to Steffen Dettmer on 3/3/2010 4:27 PM:
#
# Adds parameter to WARN_CFLAGS if the compiler supports it. For example,
# gl_WARN_ADD([-Wparentheses]).
AC_DEFUN([gl_WARN_ADD],
(If I understand correctly, this macro checks if the compiler
still runs when the flag is given.)
Yes.
Then in configure.ac, you give the user the option to request extra
compiler flags, and create an AC_SUBST variable containing the result of
the supported flags:
AC_ARG_ENABLE([gcc-warnings],
ahh, you already wrote but I just notice now, it is gcc-option.
So instead of --enable-errors we could use --enable-gcc-errors
and --enable-cl-errors.
GNU m4 named its particular configure option '--enable-gcc-warnings',
because m4's configure.ac only lists options known to belong to gcc
(although those options may also be accepted by non-gcc, in which case
they can still be detected and used). You are free to use a different
name for your configure; the name --enable-errors works nicely. In fact,
the whole point of gl_WARN_ADD is that it filters out working options from
a larger list of possible options. So, by removing the compiler name from
your enable option, and calling:
gl_WARN_ADD([-Werror], [WERROR_CFLAGS])
gl_WARN_ADD([-WX], [WERROR_CFLAGS])
you can support both compilers at once. Or even make it a shell list:
opt=
opt=$opt -Werror
opt=$opt -WX
for o in $opt; do
gl_WARN_ADD([$opt], [WERROR_CFLAGS])
done
so that adding another spelling of some other option that you find useful
becomes a matter of just tweaking $opt.
AM_CFLAGS = $(WERROR_CFLAGS)
ahh ok this way.
Before I change my 352 Makefile.am's:
- Can this do harm (e.g. in makefiles for packages without C
sources or so)?
What harm are you envisioning? It is harmless to set AM_CFLAGS in a
Makefile.am that has no C source files, but it only has an effect when
compiling C code.
- Can I simply append `AM_CFLAGS += $(WERROR_CFLAGS)' to each
Makefile.am and be done?
Probably, as long as something earlier in the file already set AM_CFLAGS.
You can even make all of your Makefile.am include a common makefile
fragment, and do the WERROR_CFLAGS manipulation only once in that common
fragment.
- should I better use something like `-include warnings.mak' or
alike to be more flexible in case I'll need it later?
Yep - that's what I was saying in the line above before I ready your question.
- Alternatively, by accident, ts there some way to tell configure
something like: right just before writing config.status, set
`CFLAGS=$CFLAGS\ $WERROR_CFLAGS' or so?
As Peter suggests?
Perhaps; AC_CONFIG_COMMANDS_PRE probably fits the bill as the ideal macro
to use for guaranteeing that you inject your shell code at the last
possible moment. I'm not sure of the ramifications of setting CFLAGS like
that, though, if the user passed in an explicit CFLAGS when they invoked
configure (if CFLAGS started life uninitialized, you are free to set it to
anything, but per GNU Coding Standards, if CFLAGS was explicitly set, you
shouldn't modify it, on the assumption that the user knows best). That's
why I recommend changing AM_CFLAGS, not CFLAGS.
- Instead of changing 352 Makefile.am's, should I change 42
configure.{in,ac} to have a line like
CFLAGS=$CFLAGS\ $WERROR_CFLAGS
right before AC_OUTPUT?
That's the same question you asked above. AC_OUTPUT _is_ the point where
config.status is written.
We now have in configure.in (or actually an included .m4
file) `CFLAGS=$CFLAGS -Werror;'
That's where you are going wrong. The recommended approach is
to modify CFLAGS in the Makefile, using an AC_SUBST, rather
than hard-coding the modification into configure.
ohh I though configure should configure the compiler flags?
Yes it should, and that's what this whole thread has been about. But in
the case of -Werror, you want to configure the flag to only be in effect
at make time, and not impact the flags to be used for the remainder of the
configure run. In other words, it is imperative that what configure
learned about -Werror be delayed until make time, rather than being
applied immediately.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: AC_CHECK_FUNCS and gcc with -Werror
According to Eric Blake on 3/3/2010 4:45 PM: AM_CFLAGS = $(WERROR_CFLAGS) ahh ok this way. Before I change my 352 Makefile.am's: By the way, I find that mass updates like this can easily be done with a decent scripting language, or even a few shell commands, rather than tediously doing it all by hand. For example, (untested, but probably close to what you want, to append given text at the end of all existing Makefile.am): script='$ a\ AM_CFLAGS += $(WERROR_CFLAGS) ' find . -name Makefile.am | xargs sed -i -e $script -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: how to handle new subdirectories?
* Steffen Dettmer wrote on Wed, Mar 03, 2010 at 12:31:44PM CET: On Wed, Mar 3, 2010 at 7:33 AM, Ralf Wildenhues wrote: * Steffen Dettmer wrote on Tue, Mar 02, 2010 at 04:25:50PM CET: For new subdirectories with new Makefile.am autoconf/automake fails because Makefile.in seems not to be created automatically, I'm not sure I understand. The normal way to add a new directory is to add AC_CONFIG_FILES([dir/Makefile]) (or add to AC_OUTPUT, seems with AC_OUTPUT, AC_CONFIG_FILES won't work) Don't do that, adding arguments to AC_OUTPUT, that's very backward and there is only one AC_OUTPUT allowed. Instead add config files to AC_CONFIG_FILES calls, that is equivalent but you can have as many of them as you like (and also specify optional additional arguments). Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
