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
information in CMakeLists.txt
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.
This module sets individual flags for each feature; there is not one
"CXX11Features_FOUND" flags which is set. Thus, when putting the
module as REQUIRED, the only consequence is that we cannot disable
searching for it.
Instead, we make it optional, meaning that the flags won't get set if
it isn't included and the dependent modules will adjust accordingly.
In CMake "canon" (i.e. tutorial on Kitware's website) it is stated that
the _DIR suffix should be used for the directory of the library alone,
whereas _DIRS are entire list of paths necessary to compile (i.e.
dependencies are included).
Eigen3 only uses the singular form (since it doesn't have any
dependencies); it should really be copied to the plural form, but it may
be advantageous to have the find-module included unchanged, so we put in
an extra effort to find it here.
If dune-grid has been compiled with _GLIBCXX_DEBUG, linking the test
program will fail since probing doesn't get the flags that are specified
for the main project, and thus configuration halts. Instead, we use a
smaller test program which doesn't need proper STL linkage to compile
and link.
On RedHat 6.4 workstation the module doesn't find the necessary system
information, and gives an error message when the last parameter to the
string function is not present.
If you just download the source, compile and install, you get the
release library. Users who want to develop the code, must do setup
in their environment.
