Define the symbol to zero (false) if unavailable. This prevents a
diagnostic message concerning an undefined preprocessor symbol when used
in the form
#if HAVE_DUNE_ISTL
/* ... */
#endif
Define the symbol to zero (false) if unavailable or unwanted. This
prevents a diagnostic message concerning an undefined preprocessor
symbol (i.e., "HAVE_AGMG") when used in the form
#if HAVE_AGMG
/* ... */
#endif
This way, there will be no compiler warnings if the symbol is used
in a way akin to
#if OPM_HAVE_BOOST
/* Boost is available */
#else
/* Boost is not available */
#endif
We failed to propagate the BOOST_\(.*\)FLAGS -> OPM_BOOST_\1FLAGS fix
(commit 6b57a00) to all clients, notably our own macro for recognising
whether or not the Boost.Test library should be linked dynamically or
statically. This commit remedies that oversight.
When OPM-Core is used as a Dune module (e.g., as enabled by commit
789bc5ca7), we stand the risk of creating multiple, conflicting
defintions of crucial <config.h> symbols (e.g. `HAVE_BOOST') and
build variables (e.g., `BOOST_CPPFLAGS' and `BOOST_LDFLAG').
Avoid this situation by prefixing these symbols with an `OPM_'
string such that Dune's `ENABLE_BOOST' solution works as intendend
in modules that are derived in the OPM context.
This allows projects which use the DUNE build system and want to use
OPM-Core to specify a dependency in their dune.module file. (i.e. they
don't have to worry about compiler and linker flags anymore.)
opm-core can still be used without having DUNE installed, though. This
means that for users which do not need/want a dependency on DUNE,
nothing changes.
v2: avoid naming conflict of the AX_BOOST_BASE macro with dune-common
by renaming it to OPM_BOOST_BASE.
v3: make the library detection work nicely
v4: Use AX_BOOST_BASE M4 macro from opm-core instead from dune-common
as base for OPM_BOOST_BASE to get rid of a few bugs, reworded
commit message. Thanks to Bård Skaflestad for the review.
Details:
Test suites based on Boost.Test must know how to include the library
support code into the executables. If the Boost.Test library is
dynamically linked, then test suites must define the pre-processor
symbol "BOOST_TEST_DYN_LINK". Otherwise, this symbol must *not* be
defined.
Resolution:
Introduce a new Autoconf macro, OPM_DYNLINK_BOOST_TEST, that defines a
secondary symbol--HAVE_DYNAMIC_BOOST_TEST--if the local computer system
uses dynamic linking. Test suites (e.g., tests/param_test.cpp) may then
inspect this symbol to determine whether or not to #define
BOOST_TEST_DYN_LINK.
Call the macro from "configure.ac".
Suggested by: Joakim Hove
Specifically:
- Enable C++, Fortran 77 and Fortran (95+) through Libtool's LT_LANG
if available and through the traditional AC_PROG_* macros if not.
This configuration is compatible with the versions of Libtool
easily available for testing. For whatever reason--possibly a
programming error in Libtool proper--invoking the AC_PROG_F*
macros either directly or through AC_REQUIRE following an LT_INIT
invocation leads to various ``expanded before required'' warnings.
Searching the Autotools mailing lists does suggest that the
interaction of C++, Fortran and Libtool is traditionally somewhat
unstable but has improved in very recent editions of Autoconf and
Libtool.
- Re-factor the LAPACK support out to a custom macro, OPM_LAPACK,
and invoke it from configure.ac.
