Specifically, file <opm/material/constants.hh> was renamed to
<opm/material/Constants.hpp> and this renaming must be reflected in
the CMake probes for opm-material.
the only reason dune-istl was required was that the spline class used
ISTL's tridiagonal matrix. Since the spline class moved into the core
(along with a more capable tridiagonal matrix), ISTL is no longer
required by opm-material.
When doing a private install of DUNE libraries, the dune.module file
is put in the lib/ directory, regardless of architecture.
This patch searches the lib/ directory as a catch-all after having
searched the platform-specific directories. This should minimize the
chance of hitting an accidentally unrelated dune.module.
If the library is found, but dune.module is not, we really should give
an error because the #ifdefs in the code will not work as intended.
Print the locations where we expect the library to appear to the console
for better tracking.
The CMAKE_NOT_USING_CONFIG_FLAGS option is really only settable by a
user that doesn't want _DEBUG or _RELEASE flags to not have effect.
If we want other flags than the platform default, we must do hairy
things like clearing them from the cache (overriding the user's
seletion if it was the same as the platform default).
The operator precedence in CMake can be surprising, so add parenthesis
to make in unambigious. Also, make it more explicit from which language
we get the default options. (They are all set from the settings given
for C++; why would have different optimization options for C and C++?)
As of 2013-09 the DUNE code that reads dune.module is not MultiArch-
aware. Thus, for a 64-bit platform it will look in lib/ on Debian and
lib64/ on RHEL.
Some components are not yet MultiArch-aware and installs to either
lib/ (Debian) or lib64/ (RHEL) on 64-bit platforms. If we need to
interface with these components, then it is nice to have such a
variable set together with the regular detection code.
During configuration some of the values for CMake properties (compiler
flags etc.) may be changed either by the user (through command line
parameters or option files), or by the configuration script itself
(setting more aggressive options or detailed debugging for instance).
This change writes many of the relevant values back into the cache so
they are available for introspection (using e.g. ccmake) or when the
rerunning the configuration without specifying all options.
The convention is to use uppercase names, in particular our own
./configure script uses this, so we should at least allow it here
(in addition to the old way for backward compatibility)
If we set a default search path ourself, then this will be used if we
specify a SuiteSparse_ROOT with error! Instead, we should just leave
our SuiteSparse_SEARCH_PATH variable empty and then let CMake fill in
its defaults. If there is a directory specified on the other hand
(indicating that we want exactly that location), only use that and
turn all the default paths completely off.
If you test the contents of a variable, this is not necessarily true
in CMake (since the contents here is a path, and not a variable name;
the default test is "does this variable exist", not "is this a non-
empty string" like in shell script)
this is required to use the exception code of opm-core in
opm-material. Also, the Dune prerequisites of opm-material can be
removed once PR #345 is merged into opm-core...
If an alternate compiler is specified, then check if this is actually
executable before assigning it so that we don't end up with specifying
an empty name to CMake. If the path does not exist, it will be preserved
so that CMake will complain with an easily identifiable error message.
Previously, specifying the compiler name with a variable
to configure ("configure CC=gcc") lead to CMake complaining
that <builddir>/$CC was not a valid path. This patch fixes
this by extracting the full path with "which <compiler>".
Should fix issue #355.
If Boost is installed in say /usr/include/boost141 and
/usr/lib64/boost141, then there is no root you can specify to pick
them both up. However, whereas Autotools uses --with-boost and
--with-boost-libdir, FindBoost in CMake changes to using two different
variables: BOOST_INCLUDEDIR and BOOST_LIBRARYDIR. Using the header
directory for BOOST_ROOT will not work (in particularily not with
old CMake versions).
CMake does not like that you specify the compiler with the environment
variables, instead preferring that you set them as cache variables.
This layer translate between the names of the the two.
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.
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.
