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.
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.
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.
for me, it was completely broken. (it worked fine if you did not want
to use it, though.) Now it (hopefully) follows the standard OPM
variable naming conventions, allows to use the internal SuperLU BLAS
library, and works fine if superLU is not installed on a system-wide
basis.
v2: cache the POST_2005 variable to make writing it to config.h more
reliable (on my kubuntu 13.04 system it did not work without it)
v3: re-add a proper "post 2005" check from newer versions of the dune tests
Seems like I forgot to include the "CheckCSourceCompiles" macro before
using it. Since it worked for me before, I'm wondering what made this
happen. Anyway, it should now work correctly in all cases.
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.
v2: incorporate Roland's nitpicks (I hope)
v3: It was decided that it's better to change the default behavior
v4: make sure the CMake syntax is correct even if the value of the
variable contains spaces (if it contains double quotes it's a
different matter, but that's pretty much a corner case, IMHO)
v5: properly escape backslash and double quote characters in the cmake
syntax
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).
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).
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)
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)
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.
If we write a blank value into the cache, we tell CMake that ERT isn't
found and it won't check again. If we delete it from the cache in case
we didn't find the directories, then CMake will run the find module
again the next time we configure. Just probing for directories is cheap
so this is no problem. This allows us to install ERT, do a reconfigure
and it will then be picked up by the build system.
If we find ERT and it doesn't compile properly, a blank value will still
be written, and it won't try again the next time, so you must wipe the
cache if you *upgrade* ERT into a newer and more compatible version.
It gets tiresome to rebuild the project everytime one makes changes to
any of the unit tests. We don't likely publish results based on the
debug code anyway, so tracking the version number there is not such a
pressing issue.
Otherwise, the library may be declared "done" before the version number
process have had any change to touch files it depends upon. This ensures
that the version number is correct before we start building the library.
Akin to config.h, we write project-version.h whenever the VCS sha hash
of the project changes. This file can then be included to embed this
into the project. Since this changes more frequently, we choose another
file than config.h. Care is also taken to not rewrite the header if the
information doesn't change, but the project is rebuilt.
We cannot generate dune.module because that file is read by dunecontrol
before the build starts. It therefore make sense to let it be the
original and let the build system read it instead of duplicating the
This module is a adaption of Andreas Lauser's OpmParseDuneModule
in opm-material, modified to handle the more sparse info provided by
the other modules as well.
It is only used in one place, where it can easily be replaced by its
expansion. The reason for removing it is that it depends on the name
of the project, and I intend to read this using a routine it the very
directory it is including, hence the need for a different approach.
The linker that is used (ld vs. gold for instance) is often hidden
when using the compiler as a front-end (to include the correct
runtime libraries).
These functions enables us to probe the linker version and reports
its finding in the log.
Developers that are working to familiarize themselves with OPM will
probably start out in CMakeLists.txt to figure out where the project
declare its dependencies, thus the list should be referred to from
there instead of inside one of the sub-modules.
The hooks are meant to be project specific, and should therefore
either know their own name or at least have access to a variable with
that name in it.
This file can be included both in the project itself, and also in the
find module for the library, so that the list of dependencies can be
maintained in only one place.
This let you specify a bunch of directory names on the command line
to *all* packages, without getting annoying warnings that they are
defined but not used.
When using LTO, the linker calls back to the compiler to figure out
where a certain symbol is defined. However, in many versions there
is apparently a bug that is triggered if a template in inlined in
both a used library and in the main program, but with different
versions of the compiler. The Boost exception class is particular
prone for this.
Thus, we disable the -lto from the development builds by default;
if anyone wants to test of the behaviour of their own compiler, they
must now explicitly turn on this flag.
By setting EIGEN3_ROOT, we can point directly to the path of the
library checkout we want to use. No other searching will then take
place.
Notice that if you have found an Eigen3 installation in a previous
configure, it will not find a new version even if you introduce the
EIGEN3_ROOT variable!
