Re: detection and support of OpenMP

[Bruno Haible]

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