- Using standard python 'import ert' and introspection.
- Using dist-packages (debian) and site-packages (!debian).
- In separate cmake module FindERTPython.cmake
for me, 4292de413f lead to linker errors
if the sequential metis library was required (and the parallel is not
installed). see e.g.,
http://www.opm-project.org/CDash/viewBuildError.php?buildid=41290
The reason for this is a partial clash in the variable names which are
used by both modules. With this PR, the FindParMETIS module does not
write to any variables that are prefixed by "METIS_".
if the 'configure' wrapper is used, you will most likely use
dunecontrol. since duncontrol explicitly passes the paths for all the
dependencies, the "convenience" of the sibling search not wanted in
most cases.
The AMG within dune-istl issues a warning if ParMETIS is not available.
The reason is that it uses ParMETIS or the ParMETIS bindings of PT-Scotch
to redistribute the load on the coarse levels. Even with an installed and
found PT-Scotch we need to adapt the include path and the libraries linked
to make it work.
Therefore this commit adds a module for searching for ParMETIS and activates
it whenever dune-istl is a dependency. With this the warning about missing
ParMETIS for flow_cp vanishes.
- pass on toolchain file
- don't build examples in static directories
- allow non-install mode and custom targets in opm_from_git
- use origin/master to make sure static source trees are built from the
top should user re-execute the build in an existing build tree
The "default default" is the source directory of the project in order
to avoid having to copy the data files which are necessary for
executing the tests. (copying them is an almost impossible thing to do
in general, since the file system layout of the project is not
standardized.) this can be changed using the new
opm_set_test_default_working_directory() macro.
having said this, some tests may have to write some output to disk
during execution and the source directory should not be assumed to be
writable (e.g., it could be burned on a DVD), i.e., using the build
directory by default would be the more sensible choice IMO.
The most important issue was that PR#20 removed the possibility to use
a test driver script. In eWoms, this script is responsible for
(fuzzily) comparing the results of the test runs with reference
solutions, to test the simulators in parallel and compare the results,
and to make sure that the --help command continues to work as
intended.
The approach taken to bring this functionality back is to specify the
test driver script and its parameters using the new macro
'opm_set_test_driver(${DRIVER_COMMAND} ${DRIVER_DEFAULT_ARGUMENTS})'
before the first call to 'opm_add_test'. If no test driver is
specified, the binary is run 'naked', so nothing should change in this
case.
