ALUGrid is needed to avoid unresolved symbols if dune-grid was
compiled with it. METIS is used by the parallel version of
ALUGrid. (Although it is not open source...)
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.
By returning a ${package}_SOURCES variable with the names of the code,
it will be propagated to ${project}_SOURCES and subsequently compiled
into the library.
AGMG (Algebraic Multigrid) uses this functionality.
Figure out where the closest dune.module is, and parse it for
information. The defines are added to config.h, so that our code
may behave differently for various versions available.
It actually works for opm-core 1.0 as well, but don't tell anyone;
we rather want people to use opm/core/version.h instead.
If a module has been backported and installed to a directory which
also contains the version number, e.g. /usr/include/dune-2.3, to
avoid clashing with an existing version in /usr/include, then this
part is now stripped from the include directory and added back to
the lib directory where we are looking for dune.module
This hook together with the bundled convenience macro makes it
possible to add the version of another module to config.h using
code like this:
macro (config_hook)
opm_need_version_of ("dune-common")
endmacro (config_hook)
The config variables in _CONFIG_IMPL_VARS are only written to config.h
and not the .pc or -config.cmake files. They can thus only be used by
the implementation files and not the headers. Use this set to avoid
exposing the variables to other projects, when it is likely that a
probe used by that other project may turn up a different result.
If you run `cmake --build . -- distclean` all generated files will
now be gone! This adds the files that have been introduced in later
improvements to the build system.
Clang aims to be compatible with GCC when it comes to command-line
parameters. Where we enable functionality based on the presence of
a GCC-compiler, we can use the same functionality with Clang.
This patch introduces a new variable CXX_COMPAT_GCC which is true if
the compiler handles the same options as GCC, and this variable is
subsequently used in tests instead of CMAKE_COMPILER_IS_GNUCXX (which
remains if we need to test if we really have GCC, e.g. for version)
Introduce a main build file which uses modules in the cmake/ directory
for most of its bulk work, which agains retrieve information from files
in the root of the source tree (dune.module, CMakeLists_files.cmake) to
get information about the project.
Thus, the cmake/ directory is shared between all the projects down to
the last bit; only project-specific customizations go into the main file
in form of _hook macros (which are called in specific places).
The difference between the version number (1.0) and the label (2013.03)
is: The version is time-independent but shows the level of compatibility,
see e.g. <http://www.semver.org>, whereas the label is a marketing tool
which describes the project progress.
The prerequisites are now declared in their own file, so it can be
included by the main system. There is thus only one canonical place
where the list of prerequisites exist.
Other modules (notably the precompiled header one) may set properties
directly on the source file; we need to separate them into categories
for which language they belong to.
The version declared for the build system (in dune.module) is checked
against what is in the source (e.g. opm/core/version.h) and if these
don't match, then issue an author warning.
This will help us keep the two version numbers in sync., since it
becomes very obvious when we don't. The benefit for this is to not have
the build system start mucking with the code just to dump some static
information in there.
When checking out from source code, the paths that were used to
configure the project should be carried on to the installed binary,
so the same libraries are used without much effort.
By using RUNPATH instead of (just) RPATH, it can be overridden with
LD_LIBRARY_PATH if the user so desires.
