On Tue, 9 Oct 2007, Bruno Haible wrote:
The usual way to handle new compilers or new platforms in autoconf is
through patching the autoconf macros. AC_PROG_CC_STDC, AC_PROG_CC_C99
cannot be extended by environment variables either.
I don't think that's true.
First, of course autoconf will have to eventually be patched if new flags
are found, but that doesn't help the users with old configure scripts and
older versions of autoconf. Environment variables are the "usual" way to
extend configure scripts for new systems, not patching autoconf macros, in
my experience.
Second, it is common for autoconf tests that have output variables to be
overridable by the user. For example, AC_CHECK_PROG etc can be
overridden, AC_FC_LIBRARY_LDFLAGS, AC_PROG_CPP, etc. Also, *FLAGS
variables in autoconf are nearly all user-extensible. Here, we output
OPENMP_*FLAGS, so it should be overridable.
Third, in the examples you gave, the user *can* override/extend by setting
CC appropriately (note that CC is modified by those macros). With the
current AC_OPENMP, you could of course add an OpenMP flag to CC/CFLAGS,
but that would not be the same because it would force that flag to be used
for *all* compilations, not just those using OPENMP_*FLAGS
Good point. How about a macro AC_DISABLE_OPENMP which changes the default
setting to off (like AM_DISABLE_SHARED in libtool)?
That seems okay to me, I suppose, although I'm more inclined just to have
a single OpenMP macro that behaves like most other autoconf macros (not
adding its own --enable/--disable option, leaving this up to the user).
Entia non multiplicanda sunt.
I would reserve a first argument to denote the OpenMP version number (to
cope with future developments of that spec), i.e. I would actually propose
AC_OPENMP(VERSION, ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
The more standard autoconf style would be to have separate tests for
particular features in new versions, e.g. an AC_OPENMP_FOOBAR test to see
if OpenMP has the FOOBAR feature from OpenMP version 12, rather than
testing for specific versions.
Regards,
Steven G. Johnson
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
