The previous version may have ended up in lib64/ instead of lib/;
now we remove the arch-specific suffix from the path, and always
use the no-arch version.
dune.module does not contain any paths to architecture-specific
binaries. It is therefore always installed in no-arch lib/ directory.
Thus, there is no need to have a variable for this, and there was
no other users of this variable either.
for me, it was completely broken. (it worked fine if you did not want
to use it, though.) Now it (hopefully) follows the standard OPM
variable naming conventions, allows to use the internal SuperLU BLAS
library, and works fine if superLU is not installed on a system-wide
basis.
v2: cache the POST_2005 variable to make writing it to config.h more
reliable (on my kubuntu 13.04 system it did not work without it)
v3: re-add a proper "post 2005" check from newer versions of the dune tests
Getting uppercase of a string can be done in a way that is compatible
with Bash 3.2. This creates a dependency on the `tr` utility, but I
reckon it will/can be available everywhere Bash 3.2 is.
If we are using the Apple toolchain on MacOS X, we must use the
newer runtime and not the old GCC 4.2 fork, in order to get the
C++11 library features (such as std::shared_ptr).
Some features, such as the Fortran wrappers, are enabled by options,
and it may be usable to have those set in a common definition file.
However, as these features are included conditionally based on use,
their option variables may not exist in other projects, giving a CMake
warning for them.
Here we list such variables too. Reading them at the end corresponds
to the Autotools convention of ignoring unknown --enable-xxx options.
SuiteSparse may or may not be installed in a suitesparse/ directory.
FindSuiteSparse will look in a suitesparse/ subdirectory when trying
to locate umfpack.h, but it will add the full directory to the compiler
command-line (e.g. `-I/usr/include/suitesparse`) and not that of the
parent. Since the parent is usually included too, it is not noticed
that it is advertedly using another include paths than its own.
However, if we have SuiteSparse installed in a non-system location,
using the subdirectory in the `#include` statement may now cause an
error, even though configuration actually found SuiteSparse!
There is no SuiteSparse headers or libraries in
/System/Library/Frameworks/Accelerate.framework on MacOS X, so adding
this directive won't contribute anything other than compiler warnings.
The earlier code assumed that the version information always follows
the full file path; this code splits the path up into various parts
so that this may be changed.
If someone is going to backport these packages, they may have an
interest in using versioned directories. These will most likely
attempt to set directories on the build command line, thus it is
most natural to insert a suggestion about this option there.
Header and library directory may be specified separately by using the
variables e.g. OPM_CORE_INCLUDE_DIR and OPM_CORE_LIB_DIR. These override
even the OPM_CORE_ROOT. This allows us to use a backported version which
uses versioned directory names.
If the option USE_VERSIONED_DIR is set to ON (default is OFF), then
most files are installed in a ${suite}-${label}/ subdirectory
(e.g. header files go in "/usr/include/opm-2013.03/"). This enables
us to easily install backports of newer versions on systems which
have a system package for an older one, without getting conflicts.
v2: incorporate Roland's nitpicks (I hope)
v3: It was decided that it's better to change the default behavior
v4: make sure the CMake syntax is correct even if the value of the
variable contains spaces (if it contains double quotes it's a
different matter, but that's pretty much a corner case, IMHO)
v5: properly escape backslash and double quote characters in the cmake
syntax
The old version invoked a Fortran compiler to figure out the bindings
necessary to link to a Fortran function. This creates a dependency on
having a Fortran compiler, even though the project may not have any
Fortran source it needs to compile!
Also, the Fortran compiler that is installed on the system may not be
the same as was used to compile the library anyway, so we are not even
sure that this is correct!
Furthermore, FindLAPACK operates on the assumption that names in that
library is suffixed with a single underscore, so if that is not correct,
we won't find any of the functions in that library anyway!
Thus, this patch enables us to assume that appending an underscore is
the right thing to do without using the compiler. This option is off by
default, but can be activated with USE_UNDERSCORING=ON (named after the
GFortran option).
This puts a test into the ${project}-config.cmake file which warns
if the client project is built with a variable which is incompatible
with the build of opm-core.
Consider this minimal project:
cmake_minimum_required (VERSION 2.8)
set (HAVE_MPI 1)
find_package (opm-core)
If linked with `-Dopm-core_DIR=` path to an opm-core tree which is
build *without* MPI-support, this will issue a warning when building
the client project.
This doesn't catch all cases (if a variable isn't defined, we cannot
know if it is an omission or if it has intentionally been left blank),
but at least it catches some.
