I originally wanted to make share_obj a class so that I could hide the
helper function, but it turned out that I needed a function after all
since a function template can be inferred from the parameters but the
type cannot from the constructor.
By returning a shared_ptr directly, the compiler can do return object
optimization.
The benchmark library uses Boost::iostreams to do decompression. Since
we only scan for the Boost dependency once, this submodule is added to
all of the projects in order to have a coherent dependency on Boost.
Headers from other libraries (notably DUNE) require definitions of
other variables than our probe process set (e.g. HAVE_UMFPACK instead
of HAVE_SUITESPARSE_UMFPACK_H). This module sets those aliases for
compatibility.
Notation implies that we are going to be given symbols which
represents values or such (which arguably could be true since the
path is a particular value, and from programming we are used to
multi-letter symbols perhaps also with whitespace, but it's a
stretch), but Terminology is more accurate, as this section
describes fits the definition better: it is a vocabulary of
technical terms.
Hat tip: @bska
Give a brief description of each of the modules that comprises the build
system, and the suffices that is used to form a virtual structure of
variables for each project.
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.
The step number is zero before the first timestep has been taken, and
one after. The step number is one before the second timestep has been
taken, and two after. This was not clear from the text.
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).
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.
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.
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++?)
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.
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.
Otherwise the compiler will probably give us a warning that these
pragmas are unknown. By default that warning is disabled with our
own build system, but we also want to be able to link to our library
without incorporating the entire build system too.
To avoid deprecation warnings the number of smoothing steps was passed
through the Criterion instead of directly to the constructor in commit
a7f32b934b.
However, due to an insufficient test matrix this was not tested using
the fast AMG variant of DUNE so it breaks the builds if
`-DHAS_DUNE_FAST_AMG` is defined.
This change should apply the same type of change to this branch as for
the others. The number of smoothing steps is put into a constant to
avoid the magic number 1 to appear in too many places (although I am
not sure the number for pre- and post-smoothing always should be the
same).
If a function is used by a template but this template is not
instantiated, the function will still be defined in the header
of a module but it won't be callable because it is in an anonymous
namespace and thus we get a warning.
This only happens in Clang; GCC consider functions referenced from
templates as used.
fixup! Don't warn about functions not emitted
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.
The state that is passed to the simulator object is directly
accessible without any encapsulation towards the client. After
the notification callback was introduced, this allows the client
to observe the state in the middle of a simulation.
However, it may be that the simulator has some internal state
which is not reflected in the state object because there is a
cost associated by flushing it into the TwophaseState format.
The notification is called back on every timestep, not just the
ones that will do reporting. It may even be that reporting is
done dynamically and is not known at the time of setup. (It is
more like a condition variable).
Consequently, flushing the state in every timestep is a bad
idea. This patch sets up a new method sync() which it is expected
that the notification will call if it needs the state for
reporting purposes.
Currently it is a no-op. It just establishes a protocol that
other, compatible implementations can also use.
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.
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.
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.
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).
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.
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.
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).
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!
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.
If we have a parallel ALUGrid, then we must also link with METIS. If
METIS is not available, then parallel ALUGrid should be disabled. If
we have a serial-only ALUGrid, then METIS is not required.
Setting CMAKE_DISABLE_FIND_PACKAGE_xxx flag should make find_package
not doing anything, but this does not seem to work with older versions
of CMake. Anyway, we can test this flag and make sure that we don't
call find_package in that case.
Also includes a check for both upper- and same-case versions of found
flag, as some modules, most notably Boost, does not set the upper-case
version of their _FOUND flag; this tests for both.
Boost does not set the BOOST_FOUND variable to indicate that the
package is found (as it would if it had used the usual routine
find_package_handle_standard_args), but rather Boost_FOUND. This
patch tests for that condition, and print some more helpful debug
messages if a prerequisite is missing.
If an optional package require further packages, those packages should
not be marked as REQUIRED because CMake will then terminate the
configuration if it is not found (although it is transitively optional).
Conversely, we should be able to specify REQUIRED prerequisites for
REQUIRED packages and have a failure cascade up to termination.
This changeset allows us to specify REQUIRED or not in the list of
prerequisites, and have OpmPackage sort of whether it should be honored
or not.
If it is already found, most packages sets a flag that makes it exit
immediately anyway. We usually cannot rerun find_package to get another
combinations of modules. Here we check the flag before we start looking
for the package to avoid the endless stream of messages.
The modules declare which configuration variables they need to have
present in config.h, not only their own but also defined in projects
using them.
However, a lot of these variables are not actually used in the headers!
This changeset removes all HAVE_XXX variables which is not present in
any opm/*.h* file in these projects, and thus there is no need for the
client to specify.
Note that only the variables used by the module *itself* should be
listed; the build system will setup the complete list from the
prerequisites.
This define is used by the unit tests; there is no reason why it should
be on the list that must be provided by other projects that use our
headers (the other projects don't use our tests).
Currently this bootstrapper only finds the macros that are located
in the cmake/ tree in this project. Projects that don't carry their
own build system can specify search locations here.
Currently only the source tree is "searched", but the template could
be expanded to look in another/more locations (or be specified
explicitly on the command-line with a --with-opm-macros= option)
By default the configure script assumes that the source is located
relative to the script itself. By allowing this to be overridden, the
script can be shared by other projects, each passing their own location
as an extra parameter.
By using a separate variable for this we can easily grep for where
the build system depends on its own location, and also change the
policy regarding this later.
Note that there is no opm-macros module; this is a "psuedo"-module
which links to an additional one (currently, the one we're in)
The interface of the class PersistentContainer changed between DUNE
2.2 and DUNE 2.3 in an incompatible way, so we need to present
different versions of the class depending on the version of DUNE linked
with. This changeset adds the version variables for dune-grid to the
list of publicly necessary #defines that must go into using
dune-cornerpoint.
Notice that this will cause the definition of DUNE_GRID_VERSION_XXX
to be added to the flags list of dune-cornerpoint. This can be seen as
either a bug or a feature. If you try to link first dune-cornerpoint to
one version and then to another version of DUNE later, there is a very
good chance that you'll end up with problems anyway.
AGMG is now under a closed-source license, meaning that results
obtained with this solver is not freely reproducible by others.
Its use is therefore discouraged.
As of version 2.3, the DUNE AMG parts are competitive, so there
is a free and open alternative.
Roland Kaufmann