OilfieldToolsNet/opm-core
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
4d00754e013305ed6ab235700b76732019b520f0
opm-core/configure.ac

65 lines
1.7 KiB
Plaintext
Raw Normal View History

Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
Now configuration succeeds for CentOS 5.7.
2011-12-12 14:57:09 +01:00
AC_PREREQ([2.59])
Avoid leading space in package name 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.
2012-09-21 12:29:22 +02:00
AC_INIT([OPM Core Library], [0.1], [atgeirr@sintef.no],
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
[opmcore], [https://public.ict.sintef.no/opm/hg/opmcore])
AM_INIT_AUTOMAKE([-Wall -Werror foreign subdir-objects])
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
Make configure.ac compatible with automake 1.12 Since automake 1.12 warnings in the category 'extra-portability' are enabled with -Wall [1]. In automake 1.11.2 the AM_PROG_AR macro was added and is required when compiling with extra-compatibility [2]. [1] http://lists.gnu.org/archive/html/automake/2012-04/msg00060.html [2] http://lists.gnu.org/archive/html/automake/2011-12/msg00055.html
2012-08-23 14:20:41 +02:00
# Needed for automake since version 1.12 because extra-portability
# warnings were then added to -Wall. Ifdef makes it backwards compatible.
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
AC_CONFIG_MACRO_DIR([m4])
Updated for changed paths.
2011-12-12 11:29:14 +01:00
AC_CONFIG_SRCDIR([opm/core/grid.h])
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
AC_CONFIG_HEADERS([config.h])
# Checks for programs.
AC_PROG_CC
AM_PROG_CC_C_O needed because of subdir objects.
2012-01-06 11:22:35 +01:00
AM_PROG_CC_C_O
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
Make LT_INIT recognizable by autoconf 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.
2012-09-21 14:28:26 +02:00
dnl Initialize libtool; the funny indentation here is to
dnl satisfy libtoolize' check for the presence of this macro
Revamp Fortran support in preparation of enabling Notay's AGMG solver. 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.
2012-06-05 18:40:36 +02:00
m4_ifdef([LT_INIT],
Make LT_INIT recognizable by autoconf 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.
2012-09-21 14:28:26 +02:00
[
LT_INIT[]dnl
Revamp Fortran support in preparation of enabling Notay's AGMG solver. 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.
2012-06-05 18:40:36 +02:00
LT_LANG([C++])dnl
LT_LANG([Fortran 77])dnl
LT_LANG([Fortran])dnl
],dnl
[AC_PROG_LIBTOOL[]dnl
AC_PROG_CXX[]dnl
AC_PROG_F77[]dnl
AC_PROG_FC[]dnl
])[]dnl
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
opm-core: make it a usable in conjunction wit dunecontrol 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.
2012-06-14 18:13:56 +02:00
OPM_CORE_CHECKS
Initial version of automatic checking for dune-istl in build system.
2012-04-13 15:35:19 +02:00
Add AC macro to determine how to link Boost.Test 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
2012-06-27 16:25:46 +02:00
OPM_DYNLINK_BOOST_TEST
Tentative refinement of ERT Autoconf support. 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.
2012-06-28 13:27:03 +02:00
ERT
Add preliminary detection of UMFPACK library (and headers).
2011-12-08 16:15:14 +01:00
Explicitly substitute absolute path variables. 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)
2012-07-12 14:37:23 +02:00
dnl Substitute Autoconf's abs_*dir variables into the Makefiles for the
dnl benefit of external code that uses these variables to derive
dnl locations (e.g., Dune's DUNE_CHECK_MODULES macro). Automakes prior
dnl to version 1.10 do not automatically substitute these variables into
dnl output files.
AC_SUBST([abs_srcdir])
AC_SUBST([abs_builddir])
AC_SUBST([abs_top_srcdir])
AC_SUBST([abs_top_builddir])
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
AC_CONFIG_FILES([
Makefile
tests/Makefile
examples/Makefile
Fixed configure.ac file to take into account tutorials
2012-04-10 17:46:52 +02:00
tutorials/Makefile
Move old pkgconfig file back to be in sync with master
2013-02-11 23:08:09 +01:00
opm-core.pc
Provide pkgconfig files for library 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.
2012-09-21 12:28:57 +02:00
lib/pkgconfig/opm-core.pc
Provide CMake config mode files for custom builds 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.
2012-10-19 14:14:15 +02:00
opmcore-config.cmake
Complete cset ad3d926031e7.
2011-12-08 14:49:09 +01:00
])
AC_OUTPUT
Reference in New Issue Copy Permalink