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!