search

OPM / opm-common

Common components for OPM, in particular build system (cmake).
http://www.opm-project.org
GNU General Public License v3.0
30 stars 112 forks source link

Detection of third-party libraries fails #517

Open berndflemisch opened 5 years ago

berndflemisch commented 5 years ago

Once I include opm-common in my dunecontrol run, it fails to detect SuperLU and SuiteSparse for descendant modules, in my case dumux.

Running the attached script install_opm.sh.txt produces the attached output opm_script_output.txt.

The detection runs fine for dune-istl before building opm-common and fails for dumux afterwards. Removing opm-*/dune.module and therefore excluding them from building lets the detection succeed.

I'd be happy to provide more information but am unsure what you need.

timokoch commented 5 years ago

If suitesparse umfpack is found by dune-istl, but not by OPM (I guess for OPM I have to manually tell it to look for it, is that right?) OPM seems to overwrite HAVE_UMFPACK (if this is true, it's not nice, especially because OPM seems to use another name for the variable, so it shouldn't be affected by the value of HAVE_UMFPACK). HAVE_UMFPACK is true when I don't have opm-common in my module stack and becomes false/unset as soon as opm-common joins the stack.

Are there any suggestions on how to resolve this issue in a setup where opm-common/opm-grid are optional dependencies, and my module relies on dune to find Suitesparse components? Do I have to check if opm-common was found and then look for SuiteSparse myself, and just use the variable provided by dune when there is no OPM present?

Additionally, it seems to be that the CMake variable HAVE_UMFPACK is actually true (used to guard some tests in CMakeLists.txt) but the C-preprocessor variable HAVE_UMFPACK is false/unset, so guarding the add_test fails and but I get a compilation error when compiling the test because UMFPACK is "missing". Does this make sense to anyone?