This code is run unconditionally each time we do a reconfigure; if the
option is added at each time, they will accumulate (needlessly) on the
command-line, making it harder to inspect the log.
If the module root is not explicitly specified, the loading of its
configuration is delegated to a find module, which does a heuristic
search in known/surrounding directories. Most OPM modules use the
common logic in OpmPackage; this patch configures the search
specifically for opm-autodiff.
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.
If the package suite was given (e.g. DUNE_ROOT=/blum), then the code
set up the root for each individual package automatically (e.g.
DUNE_COMMON_ROOT=/blum/dune-common), but the path which was then
activated did not get the local build sub-directory (e.g. if we are
building opm-autodiff in /frub/opm-autodiff/build, then the local
build directory is "build/"), and thus this was not appended to the
library search path. The result was that the source was found (because
the root pointed to a valid source tree), but the library was not
(because it is "hidden" in the subdirectory).
so far, it is only a flag which prevents the cache from being
deleted. To warn the user about a potential infinite loop, a warning
is printed if this flag was specified and some compiler or some compiler
flags were set by the user. This idea was proposed by Roland Kaufmann.
this seems to be a bug in cmake 2.8.10.2: if the user sets the
CMAKE_CXX_COMPILER variable for a build directory where this variable
has already been set, one gets an endless loop. This stings especially
if using the dunecontrol compatibility layer as the compiler flags are
unconditionally set via the CXX_FLAGS environment variable in the
options file. Running duncontrol on a module twice will thus trigger the
infinite loop if some compiler flags are set by the user.
The solution is relatively simple: Delete the CMakeFiles directory
before calling cmake. for the dunecontrol compatibility mode, we do
this in the configure script. For details about the cmake bug, see
http://www.cmake.org/Bug/view.php?id=14119
I haven't figured out why this happens, but on one of my computers
running kubuntu 13.10 g++ says the following if one tries to use
quadruple precision math:
/home/erne/src/ewoms/ewoms/common/quad.hh: In static member function ‘static quad std::numeric_limits<__float128>::min()’:
/home/erne/src/ewoms/ewoms/common/quad.hh:52:14: error: unable to find numeric literal operator ‘operator"" Q’
{ return FLT128_MIN; }
since this happens only on this machine and only with the c++ (but
not the C) compiler, i suppose that this is either an upgrade issue
with kubuntu or an issue with the ubuntu gcc stack. Strangely enough,
my other kubuntu machine does not have a problem with that...
In any case also testing for assignability of constants and using the
C++ compiler for the quadmath test won't hurt...
Some packages are split up in several library files, where each of them
doesn't have their own CMake find-module. So we cannot put this list in
the prerequisites. Unlike the headers, where we just add the directory,
all the libraries must be explicitly named on the link line. Thus, we
should allow to specify more than one name in the lib parameter.
The first name specified is designated as the "primary" library and is
assigned to the _LIBRARY variable; the others occur in _LIBRARIES as if
they were prerequisites.
Note that the build system cannot replicate this setup itself; it always
assumes that we are building (at most) one library from the source
files.
Some packages are split up in several library files, where each of them
doesn't have their own CMake find-module. So we cannot put this list in
the prerequisites. Unlike the headers, where we just add the directory,
all the libraries must be explicitly named on the link line. Thus, we
should allow to specify more than one name in the lib parameter.
The first name specified is designated as the "primary" library and is
assigned to the _LIBRARY variable; the others occur in _LIBRARIES as if
they were prerequisites.
Note that the build system cannot replicate this setup itself; it always
assumes that we are building (at most) one library from the source
files.
The previous version assumed that we had libraries, and thus always
installs the .pc file in the multi-arch library directory. However,
we now have modules which does not have a library, but whose header
files still need to be located. Since the lib/ directory is usually
in the pkgconfig search path, it is natural to put them there.
If -DSUITESPARSE_USE_STATIC=ON, then the build system will only look for
static versions of the libraries that are part of SuiteSparse, even if
dynamic/shared versions are present on the system. Thus, the default of
preferring dynamic libraries can be overridden.
SuiteSparse is rarely built ourselves, but still uncommon enough to not
be present on computing clusters.
This patch allows us to install the libraries on a workstation, for
instance from package suitesparse-devel and link to it statically
without having to maintain our own build tree.
By passing these options through ./configure, one can use dunecontrol
to build a complete stack and still get a customized description in
CDash (such as when building in a cluster or VM where the actual machine
name does not matter, or when you want to add key options to the name
shown) without having to run a second configuration just to set those
in the cache.
Also fixes a bug where --with-cmake would skip any further option
specified after it.
Assume that ./configure --with-mpi= also implies --enable-mpi; if you
absolutely want to specify path without enabling (?!) then you can do
--with-mpi=... --disable-mpi (in that order).
This patch look for anything after the equal sign of the --with
parameter and only set the variable _MPI_PREFIX_PATH if that is given;
it always toggle USE_MPI.
gdb on MacOS X does not seem to be very fond of "flat" dSYM files, but
it can read the bundle variant fine. Thus we change that to enable
debugging across several tools.
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.
