this is basically the dune-grid grid manager for ALUGrid properly
out-sourced into an own module. (it does not require an external
library anymore, so it simplifies the build quite a bit.) Also, the
DUNE-ALUGrid module has quite a few new features and performance
improvements compared to the old code from dune-grid. For details, see
http://users.dune-project.org/projects/dune-alugrid
de facto, this does not change anything because opm-parser is required
and it has a hard dependency on ERT. It is good style to declare all
prerequisites explicitly in each module, though. Thanks to [at]bska
for the catch.
this is required to make the opm-core build succeed if ERT was build
with -DBUILD_SHARED_LIBS=OFF . (without it, I get errors like
/home/and/src/ert/devel/libert_util/src/thread_pool_posix.c:328: error: undefined reference to 'pthread_create'
as there is not much harm done if it is not used but it may cause the
build to fail if it is present (read: it causes _my_ build to fail),
it defaults to OFF.
because if umfpack is fully linked but some other library is
underlinked, it causes the build to fail. This flag is better dealt
with in the "UseOnlyNeeded.cmake" module...
The build system depends on knowing if MPI is available. Explicitly
search for MPI to honour that requirement. Don't rely on ISTL's
transitive searching for the same.
recently UG has become free software (yay!), so we can now support it
with a good conscience. The CMake module is based on the "UseUG.cmake"
module of dune-grid but it is quite a bit simpler and actually
works. (I cannot see how UseUG.cmake can work without ever including
the ug-config*.cmake files...)
the UG source code is available here:
https://github.com/ugfem/ug
The "opm-parser" module is expected to become dependent upon the ERT
library. Defer searching for the parser module until we've
established whether or not ERT is availble.
Suggested by: @andlaus
While reformatting the parser-prereqs file I accidentally replaced
the feature search 'CXX11Features' with 'CXX10Features'. This
commit fixes that blunder.
In propagating the requirements for opm-benchmarks to the other
modules I accidentally removed the 'opm-parser' prerequisite (see
commit 86439d6 for details). This commit restores that prerequisite.
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.
This commit makes a few adjustments to the white-space of file
'opm-parser-prereqs.cmake' to honour the conventions of the other
*-prereqs.cmake files within the OPM project's module suites.
No functional changes.
Commit 70505ff raised opm-core's "Boost" requirement to version 1.44
in order to reflect the requirements of the opm-parser module. This
commit propagates that requirement to all other known modules.
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.
Currently opm-parser does not create opm-parser-config.cmake files. Therefore
building with duncontrol fails as it sets opm-parser_DIR. With this patch
we force CMake to always use module mode for finding which fixes this.
Instead of guessing the suffix or subdir of the build directory,
we now simply compare PROJECT_{BINARY,SOURCE]_DIR to detect it.
By this e.g. opm-core/opm-parallel is a possible build directory, too.
At least on Debian requiring version 3.1 of Eigen3 is not sufficient
according to issue #25 the minimum version is 3.1.2. This patch fixes
the required version. In addition it skips the REQUIRED option passed
to find_package(Eigen3) to make the git download work.
Fixes#25.
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 prevents to check for the same module more than once in the same
cmake run and should thus speed things up a bit as well as make the
output a bit cleaner. For this I assumed that the ${name}_FOUND cmake
variable does not get cached, which it seems like it does not...
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.
