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.
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.
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)
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.
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.
There is some code in place now to create wells for the no-deck case,
but since it does not work correctly yet, the simulator intercepts this
and throws.
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 we have checked out a newer Eigen3 directory in a sibling directory
to ours, assume that this is because the system version is obsolete and
that we want to use this one instead.
Eigen3 is a template-library, so we must compile the source code
directly together with ours instead of linking to a library.
If the build script gives us the location of a "built" Eigen3,
meaning a directory in which CMake has been run, locate the true
source directory from the cache entries.
