Commit b6cdc06b introduced heuristics to look in the parent directory
for header files alone, while leaving the path for binary files. This
is much better than adjusting the path because one does not potentially
confuse two build directories this way.
If we give an explicit directory path it is because we want a special
version to be used instead of the system version; if there is any
problems with that, we should know up-front instead of silently start
using the system version again!
When writing the variable HAVE_SUPERLU to the config.h file, an empty
string will be interpreted as "not defined". Thus, we can use both
if and ifdef preprocessor directives to check for it. If we use zero,
then we must be careful to always use if, never ifdef.
If the user has given a path to the module, then the system paths should
not be searched, as these may contain an old and outdated version. We
don't necessarily want that just because there was a problem with our
own installation!
Deleted some unused code (or moved to opm-porsol), moved all code dealing with
time-of-flight to opm/core/tof, moved code for implicit transport solver to
opm/core/transport/implicit, spu_[im|ex]plicit.[ch] to opm/core/transport/minimal.
This change is similar to commit 89be4e14: After find_package_append_to
changed from function to macro to pick up the configuration not only
from the module itself but also from everything it pulled it, the
variable MODULE is overwritten (variable module in lower case is a
parameter, so it is replaced in the source body). Thus, the test in the
end is not whether *this* module was found, but if its last dependency
was! This made the build crash only in some projects but not in others.
Some libraries require more information than what is present in the
xxx-config.cmake file, e.g. the caller must know whether HAVE_TUPLE
is available and probably used when compiling dune-common, and put
this in its own config.h file.
Code to take care of these variables must therefore be in the client
configuration, and this is the same code which is used to handle the
autotools version, namely the find module, so a practical solution
is to just revert to that in both cases.
Actually, the program spu_2p is the only place the class GravityColumnSolver
is currently used, and it is also the only program capable of doing an operator
splitting with gravity segregation being solved by full Newton-Raphson (not by
columns). These features should be made available by refactoring the transport
solvers: making the segregation solvers inherit TransportSolverTwophaseInterface
and creating a general composite solver.
