Client programs/libraries that uses CMake as their build system should
be able to point at the directory of a OPM-core build tree and have its
library picked up from there.
The LT_INIT macro is wrapped in an m4_ifdef to handle older versions of
libtool. However, the text scanning done by libtoolize cause a warning
if this statement does not match a particular search expression.
Writing the clause in this form makes the (false) warning go away.
A boilerplate .pc file is provided in the lib/pkgconfig directory. Using
this location has the advantage of being in the same path relative to
the libraries as it will be in the installation. The drawback is that the
lib/ directory no longer contains just output unless one uses out-of-tree
builds.
In the root directory of the project a local .pc file is provided which
instead of the usual end-installation directory rather points to the
build and source directories. By adding the build directory to the
PKG_CONFIG_PATH environment variable, a local build can be referred to
from other projects (such as examples or specific test-cases).
Having two different files is unfortunately necessary since pkgconfig
does not support prefix rewriting on Linux, and having them in two
different directories is necessary since the AutoMake-generated files
is not capable of renaming a file, only relocating it.
By having an M4 line comment ("dnl") at the end of the line after the
comma, it seems that the indentation is included in the string on the
next line (it does not start at the escaping bracket).
This whitespace should be removed so the PACKAGE define can be used in
for instance filenames.
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.
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.
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 .
