If a client generated with duneproject/built with dunecontrol has a
dependency to opm-core, the macros defined in this file is expected
to exist and will be called to search for the opm-core library.
All that is done here is to use the pkg-config helper module and
import the configuration that was written by the CMake system (which
even may have been called earlier in the same dunecontrol "session")
Pkg-config files are written as part of the CMake configuration, and
these can be imported into AutoTools-driven projects to get the correct
compiler and linker options that has been probed.
We inherited this test from the Dune repositories, but failed to install
sufficient protection in the form of symbol renaming to guarantee that
both tests could coexist.
This issue was exposed by a recent pull request in the OPM-Porsol
repository, namely OPM/opm-porsol#16.
There is no need to use Bash-specific operators when the pure sh(1)
built-in test operators have the exact same semantics. This increases
portability to systems for which /bin/sh is *not* Bash (or Dash).
Only probe for libraries on system if no library is specified. If there
is an error with the library that is specified as an argument, then
raise an error instead of continuing to look for other libraries with a
simple warning buried deep in the configuration log.
This enables explicitly encoding the directory, e.g., in the OPM-Core
run-path. This, in turn, reduces the burden on library clients that
would otherwise have to satisfy library link requirements in addition to
any other link requirements they might have.
This change implements the approach of (e.g.,) ax_boost_system.m4, but
may lose some of the initial refinements. In that case, we will have to
refine this code.
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.
Add a new macro, "ERT", that uses AC_LINK_IFELSE to test if the ECL and
related libraries are available of the local computer system. Call the
macro from "configure.ac".
Also, adapt the main "Makefile.am" to the results of the "ERT" macro.
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.
