Apparently, Automakes prior to 1.10 do not automatically substitute
the absolute path directory variables
abs_srcdir abs_top_srcdir
abs_builddir abs_top_builddir
that Autoconf computes (since ca. 2003) into the Makefiles. This
leads to a subtle error when OPM-Core is used in conjunction with
dune-common's DUNE_CHECK_MODULES (or, more appropriately, our own
OPM_CORE_CHECK_MODULES) macro that gets invoked through dunecontrol.
The *_CHECK_MOUDLES macro contains an unconditional statement that
uses 'abs_top_srcdir' to compute the absolute path to the current
module's top source directory. When abs_top_srcdir is unset, the
root becomes unset too, whence the subsequent existence and validity
checks fail due to incorrect CPPFLAGS and/or LDFLAGS. It will also
fail to locate the 'dune.module' dependency file.
By explicitly substituting the above variables into the Makefiles,
as was also done in revisions 5819 and 5845 of dune-common's
Subversion repository, we're guarding against this particular
failure mode.
Tested on: CentOS 5.8 (Autoconf 2.59, Automake 1.9.6)
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.
The former depends on the latter, whence the latter must be brought in
before the former.
While here, include checks for additional library components that may
be needed to satisfy all UMFPACK dependencies in more recent editions
of the SuiteSparse package.
Issue noticed by: Joakim Hove
Specifically, bring in maths library through AC_SEARCH_LIBS and add
checks for sqrt() and pow() only after we've established which library
might contain these functions. Similarly, rely on AC_SEARCH_LIBS
adding -lamd to ${LIBS} if needed in which case it is not necessary to
manually bring these libraries in while searching for UMFPACK.
Finally, add check for memset(). Needed by Tarjan implementation.
Specifically, we don't (currently) use per-target compilation or
linking flags, and therefore do not need a portability aid in our
current build process.
Automake 1.11 introduced the concept of "silent build rules" wherein the
build commands are reported as
CC spu_explicit.lo
rather than something along the lines of
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../../opmtransport/src -I.. -O3 -DNDEBUG -Wall -Wextra -std=c99 -pedantic -march=native -mtune=native -MT spu_explicit.lo -MD -MP -MF .deps/spu_explicit.Tpo -c -o spu_explicit.lo ../../../../../opmtransport/src/spu_explicit.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../../opmtransport/src -I.. -O3 -DNDEBUG -Wall -Wextra -std=c99 -pedantic -march=native -mtune=native -MT spu_explicit.lo -MD -MP -MF .deps/spu_explicit.Tpo -c ../../../../../opmtransport/src/spu_explicit.c -fPIC -DPIC -o .libs/spu_explicit.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../../opmtransport/src -I.. -O3 -DNDEBUG -Wall -Wextra -std=c99 -pedantic -march=native -mtune=native -MT spu_explicit.lo -MD -MP -MF .deps/spu_explicit.Tpo -c ../../../../../opmtransport/src/spu_explicit.c -o spu_explicit.o >/dev/null 2>&1
The former is much easier to read and, consequently, more conducive to
visually noticing diagnostics from the toolset (compiler, linker &c).
On the other hand, only fairly recent editions of Automake have the
"silent rule" capability, so enable silent rules only if available. In
particular, Automake 1.10.x (the default Automake version in MacOS X
10.6) does not support the capability. Neither does the default
Automake in CentOS 5.6.
Further details on silent build rules can be found at
http://sources.redhat.com/automake/automake.html#Optionshttp://www.flameeyes.eu/autotools-mythbuster/automake/silent.html
Thanks to Arne Morten Kvarving in Dune Flyspray issue #922
(http://www.dune-project.org/flyspray/index.php?do=details&task_id=922)
for the tip on how to preserve "configure.ac" backwards compatibility
with Automake < 1.11 .
