for some of these files this is needed to make to keep it compiling
after the next patch because the new ErrorMacros.hpp file will no
longer implicitly includes <iostream>. for the remaining files it is
just good style.
While at it, the includes for most of these files have been ordered in
order of decreasing abstraction level.
The state that is passed to the simulator object is directly
accessible without any encapsulation towards the client. After
the notification callback was introduced, this allows the client
to observe the state in the middle of a simulation.
However, it may be that the simulator has some internal state
which is not reflected in the state object because there is a
cost associated by flushing it into the TwophaseState format.
The notification is called back on every timestep, not just the
ones that will do reporting. It may even be that reporting is
done dynamically and is not known at the time of setup. (It is
more like a condition variable).
Consequently, flushing the state in every timestep is a bad
idea. This patch sets up a new method sync() which it is expected
that the notification will call if it needs the state for
reporting purposes.
Currently it is a no-op. It just establishes a protocol that
other, compatible implementations can also use.
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.
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.
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
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).
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.
SuiteSparse may or may not be installed in a suitesparse/ directory.
FindSuiteSparse will look in a suitesparse/ subdirectory when trying
to locate umfpack.h, but it will add the full directory to the compiler
command-line (e.g. `-I/usr/include/suitesparse`) and not that of the
parent. Since the parent is usually included too, it is not noticed
that it is advertedly using another include paths than its own.
However, if we have SuiteSparse installed in a non-system location,
using the subdirectory in the `#include` statement may now cause an
error, even though configuration actually found SuiteSparse!
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.
