autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: detection and support of OpenMP


From: Steven G. Johnson
Subject: Re: detection and support of OpenMP
Date: Mon, 8 Oct 2007 12:45:19 -0400 (EDT)

Thanks for your response, Bruno.

The commonalities in the final version were what I had based my judgement on, since the final version not only uses the same list of flags to try, but also tries them on all compilers just as in my version, and uses the same tricks with _AC_LANG_PREFIX etc. to be language-independent, uses the same OPENMP_[]_AC_LANG_PREFIX[]FLAGS output variable, and uses a similar idea of linking omp_get_num_threads to test whether things work (I used omp_set_num_threads).

That said, I'm fine with the proposed ChangeLog entry.

Steven

PS. In the future, when incorporating a new macro into autoconf for which there is a similar macro in the archive, it might be useful to drop the archive-macro author an email, since they might have relevant experience to contribute.

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.

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. 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. For example, what if the caller wants --disable-openmp to be the default, with an --enable-openmp help string? Or what if they want an --enable-parallel option that can enable OpenMP, threads, or some other mechanism depending upon what is detected? Or...

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. (For example, if it succeeds the caller might want to #define something, or if it fails they might want to look for pthreads as a fallback, or...).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]