Steven G. Johnson wrote:
> PPS. In my original macro, I also allowed the user to override the
> OPENMP_*FLAGS via an environment variable. You didn't do this in the
> autoconf version, but it might be a good idea in case a future compiler
> needs some other flag.
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.
Btw, when you are doing porting of numerous packages to a new platform,
you will come to hate the way it's done in autoconf and libtool - you
need to patch every copy of libtool.m4 and regenerate all configure and
Makefile.in files. And you will love it when the platform dependent
information is abstracted into a separate file - config.guess, config.sub,
config.rpath, config.charset or similar, because then you only need to
replace that file; no need to regenerate the configure files.
> PPPS. I notice that in the autoconf version you added --disable-openmp
> AC_ARG_ENABLE. If you do this, you should probably also add a HAVE_OPENMP
> #define so that the program can disable omp.h includes and calls to
> omp_get_num_threads etc.
The program already must have "#ifdef _OPENMP" around all uses of <omp.h>
and OpenMP functions. What usecase do you have in mind for HAVE_OPENMP
then? Is it to allow the program to be built without OpenMP, even when
the user specified
CC="gcc -fopenmp" CPP="gcc -E -fopenmp"?
> Better yet, remove it entirely...for most
> autoconf macros, if the user wants an --enable/--disable option, they
> should add it themselves, and it's not clear why AC_OPENMP is different.
The ability to --disable-openmp is welcomed by distributors. Some don't
want a dependency to a library which is only available with some compiler
versions. Others may experience bugs in the OpenMP support on some platforms.
Putting this --enable/--disable option into autoconf ensures that its spelling
is the same among package. There's no point in package A calling it
--enable-openmp, package B calling it --enable-multithread, package C
calling it --enable-parallel, and package D not having this option at all.
It's simpler for the installer if it's the same name everywhere.
> For example, what if the caller wants --disable-openmp to be the default,
> with an --enable-openmp help string?
Good point. How about a macro AC_DISABLE_OPENMP which changes the default
setting to off (like AM_DISABLE_SHARED in libtool)?
> PPPPS. My original macro has semantics
> AX_OPENMP([ACTION-IF-FOUND[, ACTION-IF-NOT-FOUND]])
> whereas the autoconf version takes no arguments. I would strongly
> recommend adding the arguments similar to my version, to allow the caller
> to perform some action depending upon whether it succeeds or fails.
You mean, some additional action? I.e.
AC_OPENMP(ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
being equivalent to
AC_OPENMP
AC_LINK_IFELSE([_AC_LANG_OPENMP], ACTION-IF-FOUND, ACTION-IF-NOT-FOUND)
Yes, why not?
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)
Bruno
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
