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.
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.
that one was due to the fact that the constructor arguments were no
longer used to initialize (unused) private member variables. These
warnings did not appear in CLang for some reason. Again, thanks to
Bård Skaflestad for the review.
'work' is a small, constant size array for temporary data so it can be
allocated on the stack and the 'work' parameter can be eliminated entirely.
Thanks to Bård Skaflestad for the suggestion!
most of them quite insignificant, but still annoying. The only
exception is the warning about the changed alignment for the 'work'
argument of spu_implicit_assemble(). AFAICT, the only reason why it
worked was that the pointer produced by malloc() was passed
directly. (malloc() seems to fulfill all alignment criteria.) To fix
this, I've changed that argument's type from char* to double*.
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 current implementations of IncompPropertiesInterface are very
all-or-nothing. In some situations, you want to read rock and fluid
properties from an Eclipse file, but use analytical functions for
the unsaturated properties. Or you want to update properties based
on a marching filter.
This patch provides a way to mix various property objects, or to
"shadow" the properties with a raw array of data, so you don't have
to reimplement the entire interface just to make a small change.
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.
If verbosity is true, we set the iprint parameter such that the
output is print to standard out. If not, we use a negative number
such that only error messages are printed to standard out.
