The CMAKE_NOT_USING_CONFIG_FLAGS option is really only settable by a
user that doesn't want _DEBUG or _RELEASE flags to not have effect.
If we want other flags than the platform default, we must do hairy
things like clearing them from the cache (overriding the user's
seletion if it was the same as the platform default).
The operator precedence in CMake can be surprising, so add parenthesis
to make in unambigious. Also, make it more explicit from which language
we get the default options. (They are all set from the settings given
for C++; why would have different optimization options for C and C++?)
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.
During configuration some of the values for CMake properties (compiler
flags etc.) may be changed either by the user (through command line
parameters or option files), or by the configuration script itself
(setting more aggressive options or detailed debugging for instance).
This change writes many of the relevant values back into the cache so
they are available for introspection (using e.g. ccmake) or when the
rerunning the configuration without specifying all options.
The convention is to use uppercase names, in particular our own
./configure script uses this, so we should at least allow it here
(in addition to the old way for backward compatibility)
If we set a default search path ourself, then this will be used if we
specify a SuiteSparse_ROOT with error! Instead, we should just leave
our SuiteSparse_SEARCH_PATH variable empty and then let CMake fill in
its defaults. If there is a directory specified on the other hand
(indicating that we want exactly that location), only use that and
turn all the default paths completely off.
If you test the contents of a variable, this is not necessarily true
in CMake (since the contents here is a path, and not a variable name;
the default test is "does this variable exist", not "is this a non-
empty string" like in shell script)
make all non-implementation headers includable without
preconditions. Also, this removes the GravityColumnSolver.hpp file,
because it tried to include a non-existing file and it was thus unused.
The OPM_THROW macro uses an internal symbol, 'oss', which is, strictly
speaking, in the client's namespace. Moreover, as the
"EclipseGridParseHelpers.hpp" header uses the same symbol, and for
similar purposes, this produces warnings at "-Wshadow" in GCC when
compiling that header.
Rename the macro's symbol to 'oss__' (double trailing underscore) to
reduce the likelihood of shadowing a previous definition.
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 an alternate compiler is specified, then check if this is actually
executable before assigning it so that we don't end up with specifying
an empty name to CMake. If the path does not exist, it will be preserved
so that CMake will complain with an easily identifiable error message.
this class can do both, more and less than dune-istl's BTDMatrix. more
because it supports entries on the lower left and upper right, less
because it does not support a block structure. The primary motivation
for this class were the spline classes which for which the former
feature is required to implement periodic splines and the latter is
not necessary...
This works pretty much the same way as DUNE_DEPRECATED (without message).
Thanks to Elias Pipping for implementing this.
dune-common SVN revision: r6556
The previous text contained an ambiguity of the contents of the field
global_cell in case it was non-null; this could be interpreted as if
the grid was non-Cartesian. However, this is not the convention that
has been followed in current clients.
The new text writes a warning about this, as well as giving a tip on
how an unstructured grid may be signaled through the structure (the
cartdims field is zero-initialized in the create_empty_grid function,
so this array must be actively initialized by the client).
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.
