Cannot create a module thats depends on dune-cornerpoint

[berndflemisch]

When I try to build a Dune module that depends on dune-cornerpoint, cmake fails because apparently the variable "dune-cornerpoint_PREFIX" is not set correctly, see the output below. The output was generated for a fresh module named "test" created with duneproject that should depend on dune-grid and dune-cornerpoint. The problem should be easy to reproduce.

I use DUNE 2.3.1 and the 2015.04 release of dune-cornerpoint.

--- calling all for test ---
--- calling vcsetup for test ---
--- calling autogen for test ---
Skipping dune-autogen because of CMake
--- calling configure for test ---
----- using default flags $CONFIGURE_FLAGS from /temp/bernd/DUMUX23/cmake5.0.opts -----
WARNING: could not find module parallelgrid,
       module is also unknown to pkg-config.
       Maybe you need to adjust PKG_CONFIG_PATH!
       parallelgrid is suggested by dune-cornerpoint
Skipping parallelgrid!
/temp/bernd/local/DUNE23CMake50/lib/dunegeometryam2cmake.lib for converting options does not exist
/temp/bernd/local/DUNE23CMake50/lib/duneistlam2cmake.lib for converting options does not exist
/temp/bernd/DUMUX23/opm-parser/lib/opmparseram2cmake.lib for converting options does not exist
/temp/bernd/DUMUX23/opm-core/lib/opmcoream2cmake.lib for converting options does not exist
/temp/bernd/DUMUX23/dune-cornerpoint/lib/dunecornerpointam2cmake.lib for converting options does not exist
/temp/bernd/DUMUX23/test/lib/testam2cmake.lib for converting options does not exist
 CXXFLAGS="-Wall -Wunused -Wmissing-include-dirs -Wcast-align -Wno-sign-compare -Wno-packed-bitfield-compat -Wno-unused-parameter -Wno-unused-local-typedefs -Wno-deprecated-declarations -Wno-literal-suffix -Wunused-but-set-variable -fno-strict-aliasing -DHAVE_NULLPTR=1" cmake -DCMAKE_MODULE_PATH=""  -DUSE_MPI=ON "-Ddune-common_DIR=/temp/bernd/local/DUNE23CMake50/lib64/cmake/dune-common" "-Ddune-geometry_DIR=/temp/bernd/local/DUNE23CMake50/lib64/cmake/dune-geometry" "-Ddune-grid_DIR=/temp/bernd/local/DUNE23CMake50/lib64/cmake/dune-grid" "-Ddune-istl_DIR=/temp/bernd/local/DUNE23CMake50/lib//cmake/dune-istl" "-Dopm-parser_DIR=/temp/bernd/DUMUX23/opm-parser/build-cmake-gcc50" "-Dopm-core_DIR=/temp/bernd/DUMUX23/opm-core/build-cmake-gcc50" "-Ddune-cornerpoint_DIR=/temp/bernd/DUMUX23/dune-cornerpoint/build-cmake-gcc50" -DDUNE_GRID_EXPERIMENTAL_GRID_EXTENSIONS=1 -DDUMUX_BUILD_ALL_TESTS:BOOL=FALSE -DCMAKE_MODULE_PATH=/temp/bernd/local/DUNE23CMake50/share/cmake/modules -DCMAKE_PREFIX_PATH="/usr/lib64/mpi/gcc/openmpi;/temp/bernd/external/metis-5.1.0;/temp/bernd/external/ALUGrid-1.52;/temp/bernd/external/ug-3.12.1;/temp/bernd/DUMUX23/ert;/temp/bernd/local/DUNE23CMake50;/temp/bernd/local/DUNE23CMake50/share;/temp/bernd/local/DUNE23CMake50/share/cmake/modules;/temp/bernd/local/DUNE23CMake50/share/cmake/scripts;" -DCMAKE_BUILD_TYPE=release -DCMAKE_CXX_COMPILER=/usr/bin/g++-5 -DCMAKE_C_COMPILER=/usr/bin/gcc-5 -Wno-dev --verbose --release -DCMAKE_DISABLE_FIND_PACKAGE_MPI=false "/temp/bernd/DUMUX23/test"
-- Dependencies for test: dune-grid;dune-cornerpoint
dune-grid, /temp/bernd/local/DUNE23CMake50
-- Dependencies for dune-grid: dune-common (>= 2.3);dune-geometry (>= 2.3)
dune-cornerpoint, 
CMake Error at /temp/bernd/local/DUNE23CMake50/share/dune/cmake/modules/DuneMacros.cmake:196 (message):
  Could not find dune.module file for module dune-cornerpoint in ,
  /lib/dunecontrol/dune-cornerpoint/
Call Stack (most recent call first):
  /temp/bernd/local/DUNE23CMake50/share/dune/cmake/modules/DuneMacros.cmake:350 (find_dune_package)
  /temp/bernd/local/DUNE23CMake50/share/dune/cmake/modules/DuneMacros.cmake:393 (dune_process_dependency_leafs)
  /temp/bernd/local/DUNE23CMake50/share/dune/cmake/modules/DuneMacros.cmake:417 (dune_create_dependency_leafs)
  /temp/bernd/local/DUNE23CMake50/share/dune/cmake/modules/DuneMacros.cmake:546 (dune_create_dependency_tree)
  CMakeLists.txt:19 (dune_project)

-- Configuring incomplete, errors occurred!
See also "/temp/bernd/DUMUX23/test/build-cmake-gcc50/CMakeFiles/CMakeOutput.log".

[andlaus]

the issue is an incompatibility of the Dune CMake build system and the one of OPM (which is also based on CMake, but disjoint from Dune's ATM). as a workaround you can set USE_CMAKE=no in the opts dunecontrol file.

[berndflemisch]

Do you mean that I should use autotools for my module? That's not an option, we only use cmake.

[andlaus]

Do you mean that I should use autotools for my module?

not necessarily: you can also use the OPM build system, but that's probably equally unfeasable for you.

Given the circumstances, you should consider opening an issue on https://github.com/OPM/opm-cmake/issues to implement compatibility with the Dune cmake build system, because so far downstream modules which don't use the OPM build system have not yet been on the agenda at all. (and I have doubts that they will be in the near to medium term future -- but who knows, where there's a will (or money), there's a way.)

[alfbr]

Just to be clear on the use case, are we talking about using an opm module in dumux as a dependency? If so, Andreas can you enlighten us about what we need to do to accommodate it?

[atgeirr]

I may be rusty on this, but I thought that it was possible to use dunecontrol to build opm and dune modules as one big happy family, have I misunderstood this?

Anyway, it seems to me that the error manifests as not being able to find dune.module: that file is provided, so this should be fixable I hope (not being enough of a cmake guru to see how, apart from manually specifying locations).

[andlaus]

Just to be clear on the use case, are we talking about using an opm module in dumux as a dependency?

I guess yes: As far as I can see, Bernd wants to write a simulator for Dumux using Dune::CpGrid as grid. IMO that's a legitimate use case -- the problem is that the Dune cmake build system (used by Dumux) and OPM's build system are currently mutually exclusive.

I can see two fixes for this:

1) keep the current build system, but change the naming conventions for all CMake variables to the ones of Dune. 2) fully switch to the Dune cmake build system.

both are major endeavours, but I'd chose (2) if I had to decide this. (Also note that maybe I'm too pessimistic and may be sufficient to write a separate Finddune-cornerpoint.cmake module for the Dune build system. I would have to investigate the feasibility of that, though.)

I may be rusty on this, but I thought that it was possible to use dunecontrol to build opm and dune modules as one big happy family, have I misunderstood this?

yes, it is possible to use dunecontrol to build OPM, and OPM modules can also specify dependencies on Dune modules. As far as I can see, the reverse is not easily possible, though.

[alfbr]

Agreeing on naming conventions, in other words 1), sounds like a minor effort. Is there something I am missing?

[andlaus]

Is there something I am missing?

you miss the fact that the naming conventions are often implicit and not easy to discover: often variable names are constructed from their pieces.

[berndflemisch]

Andreas is right about my use case: I want to use a Cpgrid in Dumux. This used to work when the Dumux build system could be based on autotools. Since we fully switched to Dune-style cmake, it doesn't work anymore.

I am currently creating a temporary workaround by manually specifying cmake variables. Compilation already works by setting dune-cornerpoint_PREFIX, opm-parser_PREFIX and opm-core_PREFIX. I still have trouble with linking since I cannot overwrite the _LIBRARIES variables. Once I have it working, I will post it as a temporary workaround.

To me, one of the most fundamental deliverables of dune-cornerpoint is an easy generation and handling of a CpGrid from within any other Dune module. A seamless integration would be most welcome.

[berndflemisch]

I have a workaround:

1. Set dune-cornerpoint_PREFIX, opm-parser_PREFIX and opm-core_PREFIX in the CMAKE_FLAGS of my Dune options file.
2. Replace Findopm-parser.cmake by using find_opm_package analogous to the other Findopm... files. This also means adding a file opm-parser-prereqs.cmake.
3. Comment lines 84-87 of opm-parser's CMakeLists.txt:

   set(opm-parser_LIBRARIES Parser opm-json)

   if(NOT BUILD_SHARED_LIBS)

   list(APPEND opm-parser_LIBRARIES cjson)

   endif()

If you think that 2. is of general interest, I could open an issue / pull request for opm-parser. If you like a pull-request, I would need your guidance on how to do this technically.

One difficulty that I had to face is that the CMake infrastructure of opm-parser is very different from the one found in the other OPM modules. I would guess that opm-parser still has to be adjusted?

Another question: Is there a reason to provide multiple Findopm... files? For example, Findopm-parser.cmake is included in opm-parser, opm-core, dune-cornerpoint... They are not even equal, the one in opm-parser is different from the others. Do you know which one actually is taken if I build dune-cornerpoint / a module depending on dune-cornerpoint?

[bska]

For example, Findopm-parser.cmake is included in opm-parser, opm-core, dune-cornerpoint

Are you using the master sources or the 2015.04 release versions? It is true that we did use to duplicate the code for the CMake system probes in every module, but with the introduction of opm-cmake--after the 2015.04 release--that is no longer the case. Opm-cmake is the centralised host of all build-system related code distributed by the OPM project.

[berndflemisch]

I use the 2015.04 release.

[bska]

I use the 2015.04 release.

Right, thanks for that information. I don't recall the details at this moment, maybe @akva2 could comment, but you really should be able to say

Find_Package (opm-core)

and so on--at least if you're using installed versions of the OPM modules.

[berndflemisch]

Writing find_package's at the beginning of the top-level CMakeLists.txt in Dumux doesn't help and gives the same error message. I guess the reason is that CMake is not called directly and the error already occurs in the part of the dunecontrol script before the added calls to find_package.

[atgeirr]

Since the last release, we have made substantial changes to the build system, notably the duplication of macros is (almost) completely gone, all now live in the new opm-common module. I suspect that the issue still remains though: could you verify that with the latest master branches, @berndflemisch?

Be aware that dune-cornerpoint (unfortunately) has a greatly expanded list of opm modules it depends on (opm-common, opm-parser, opm-material, opm-core), however that should contract again after the upcoming release (we are in the process of reorganizing our modules but have not yet deleted any).

[atgeirr]

It would be good to know if it still is troublesome to use opm-grid as an upstream module. Do you have any information @berndflemisch? Otherwise I'll probably close this issue. @andlaus and @dr-robertk, you could perhaps also weigh in on this?

[berndflemisch]

With 2016.04, it still is. I still have to pass manually the opm...PREFIX variables and HAVE_OPM_GRID to CMake. I also have to patch opm-common opm-common-2016.04.patch.txt and opm-parser opm-parser-2016.04.patch.txt.

Most likely, this is due to my very peculiar setup. I install opm to non-standard locations and try to find it from a completely different location.

Is it worth testing the master?

[berndflemisch]

Ideally, I would like to specify that non-standard location in the CMAKE_PREFIX_PATH only, something like:

-DCMAKE_PREFIX_PATH=/temp/bernd/local/DUNE24GCC5

That doesn't seem to be sufficient.

[atgeirr]

Thank you Bernd, since the issue still applies we will not close it. I took a look at your patches, but realized I do not know the build system well enough to debug this. I believe what you want is reasonable, but don't know how to fix it.

Long ago you had this as part of your workaround: "Replace Findopm-parser.cmake by using find_opm_package analogous to the other Findopm... files. This also means adding a file opm-parser-prereqs.cmake." I guess that is now handled with the patch to Findopm-parser.cmake? In any case I wonder if we really need a special find routine for opm-parser. It is special in that it requires code generation, but finding it should be similar to other modules.

[berndflemisch]

Yes, I don't need an extra file anymore. I will redo the steps of installing and finding to give you the detailed output.

[akva2]

hmm. seems to work fine for me.

built ert, opm-common, opm-parser, opm-output, opm-core, opm-grid and installed to prefix $HOME/opm/prefix1

then did a simple test project using opm-grid, passing the prefix path. all good. all it took was

find_package(opm-common REQUIRED)
find_package(opm-grid REQUIRED)

are you using dunecontrol ? cannot fix what i cannot reproduce :/

as a reference i have been doing prefix / installation based builds for opm regularly since 2012 or thereabout, so there must be more to this.

[berndflemisch]

Yes, this is about using dunecontrol.

[atgeirr]

Yes, this is about using dunecontrol.

I believe @andlaus and @dr-robertk are also building OPM with dunecontrol, which is why I tagged them earlier.

[akva2]

right.

<friday-tongue-in-cheek-mode>
  so iow do things like nature intended and things work. use complicated unnecessary
  custom third party wrapping for nature and it doesn't.
</friday-tongue-in-cheek-mode>

the problem is that dune-control passes _DIR and that hits a path in the build system i try to totally ignore, as it's only used with dune-control and i always found dune-control severely buggy. i will put it on my todo. but i fear my answer will be 'dune-control is just too broken'. it was last time i looked into it.

[berndflemisch]

I would heavily welcome a CMake-only solution for Dune. Before a fantastic CMake guru contributes a working solution, I'm bound to dunecontrol.

[atgeirr]

I build Dune with dunecontrol in a separate directory, then build OPM modules with CMake only (in another separate directory). This works quite well since I rarely need to update Dune.

[andlaus]

@andlaus and @dr-robertk, you could perhaps also weigh in on this?

Since you asked for it: as far as I can see, for projects which are not using the OPM build system, currently the best solution is to handle all OPM modules completely manually, i.e., writing stand-alone build system macros like for any other dependency (like e.g. SuperLU). I know this is really cumbersome, but the same argument basically applies to most other non-trivial build systems (in particular: Dune's).

I believe @andlaus and @dr-robertk are also building OPM with dunecontrol, which is why I tagged them earlier.

For me dunecontrol works like a charm, but I'm still using it with the autotools wrapper, so I'm limited to Dune <= 2.4. @dr-robertk uses it with cmake and dune's master, but I'm not familiar with that.

[berndflemisch]

I just tried building opm-parser with ert both from the current master and got

cd /temp/bernd/Opm/opm-parser/build-gcc6/opm/parser/eclipse && /usr/bin/cmake -E cmake_link_script CMakeFiles/createDefaultKeywordList.dir/link.txt --verbose=1
/usr/bin/g++-6   -pipe -std=c++0x  -std=c++11 -Wall -fopenmp -O3 -DNDEBUG -mtune=native -pipe -std=c++0x  -std=c++11 -Wall -O3 -DNDEBUG   CMakeFiles/createDefaultKeywordList.dir/Parser/createDefaultKeywordList.cpp.o  -o ../../../bin/createDefaultKeywordList -rdynamic ../../../lib64/libbuildParser.a ../../../lib64/libopmjson.a -lboost_filesystem-mt -lboost_date_time-mt -lboost_system-mt -lboost_unit_test_framework-mt -lboost_regex-mt /temp/bernd/local/Opm/lib64/libopmcommon.a -lpthread -lboost_filesystem-mt -lboost_date_time-mt -lboost_system-mt -lboost_unit_test_framework-mt -lboost_regex-mt /usr/local/lib64/libecl.so /usr/local/lib64/libeclxx.so /usr/local/lib64/libecl_well.so /usr/local/lib64/libert_geometry.so /usr/local/lib64/libert_util.so /temp/bernd/local/Opm/lib64/libert_utilxx.so -lz -llapack -lblas -lm -ldl -Wl,-rpath,/usr/local/lib64:/temp/bernd/local/Opm/lib64 
/temp/bernd/local/Opm/lib64/libert_utilxx.so: undefined reference to `test_work_area_alloc_input_path'
collect2: error: ld returned 1 exit status
opm/parser/eclipse/CMakeFiles/createDefaultKeywordList.dir/build.make:117: recipe for target 'bin/createDefaultKeywordList' failed

Is this something known?

[akva2]

need newer ert.

[berndflemisch]

As I said, I just built it from the current master.

[andlaus]

As I said, I just built it from the current master.

seems like you've got an older version installed on your system and the build system probably used this one...

[andlaus]

the locations of the shared libraries (/usr/local/lib64/libecl.so and /usr/local/lib64/libeclxx.so) seem suspicious...

[berndflemisch]

You're right, thank you. Removing the old ert from the standard location helps.

[berndflemisch]

Building opm-parser with gcc6 and -std=c++14 gives

/temp/bernd/Opm/opm-parser/opm/parser/eclipse/Deck/DeckItem.hpp:84:21: error: expected primary-expression before ‘)’ token
         type typeof() const;

Does that mean that I'm bound to -std=c++11 and therefore to Dune 2.4?

[akva2]

apart from the unfortunate symbol name (see https://github.com/OPM/opm-parser/pull/940) i find it interesting that gcc seems to have turned on the extension with c++14 and apparently does not with c++11.

in general the code is not tested with c++14 and you are on your own (feel free to raise any issues popping up) as such.

[berndflemisch]

Thanks for the clarification. So a merge of OPM/opm-parser#940 would be highly appreciated.

By default, gcc uses -std=c++11. I would like to force it to use -std=c++14 by setting -DCMAKE_CXX_STANDARD=14. With c++11, errors occur if headers from Dune 2.5 are included, for example, already in opm-material:

[ 46%] Building CXX object CMakeFiles/test_fluidmatrixinteractions.dir/tests/test_fluidmatrixinteractions.cpp.o
In file included from /temp/bernd/local/DUNE25GCC6/include/dune/common/fvector.hh:16:0,
                 from /temp/bernd/Opm/opm-material/opm/material/fluidmatrixinteractions/ThreePhaseParkerVanGenuchtenParams.hpp:31,
                 from /temp/bernd/Opm/opm-material/opm/material/fluidmatrixinteractions/ThreePhaseParkerVanGenuchten.hpp:30,
                 from /temp/bernd/Opm/opm-material/tests/test_fluidmatrixinteractions.cpp:46:
/temp/bernd/local/DUNE25GCC6/include/dune/common/typetraits.hh:530:62: error: ‘decay_t’ is not a member of ‘std’
   struct IsIntegralConstant : public Imp::IsIntegralConstant<std::decay_t<T>>

[akva2]

ah, yes, due to.. reasons.. we cannot yet use the cmake cxx standard support, as we need to support cmake >= 2.8. can i see a make VERBOSE=1 please, i suspect it won't hold -std=c++14 at all.

[berndflemisch]

I even get two -std=... by default:

[  1%] Building CXX object opm/parser/eclipse/CMakeFiles/buildParser.dir/RawDeck/StarToken.cpp.o
cd /temp/bernd/Opm/opm-parser/build-gcc6/opm/parser/eclipse && /usr/bin/g++-6   -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_TEST_DYN_LINK -DHAVE_CASE_SENSITIVE_FILESYSTEM=1 -DOPM_PARSER_DECK_API=1 -I/temp/bernd/Opm/opm-parser/build-gcc6/generated-source/include -I/temp/bernd/Opm/opm-parser -I/temp/bernd/Opm/opm-parser/build-gcc6 -I/temp/bernd/Opm/opm-parser/opm/json -I/temp/bernd/local/Opm/include  -pipe -std=c++0x  -std=c++11 -Wall -fopenmp -O3 -DNDEBUG -mtune=native -pipe -std=c++0x  -std=c++11 -Wall -O3 -DNDEBUG   -o CMakeFiles/buildParser.dir/RawDeck/StarToken.cpp.o -c /temp/bernd/Opm/opm-parser/opm/parser/eclipse/RawDeck/StarToken.cpp

With -DCMAKE_CXX_STANDARD=14, I get the same, but with -std=gnu++14 added after the -DNDEBUG. My CMake version is 3.4.3.

[akva2]

yes, and the lowest takes precedence iirc. please try with https://github.com/OPM/opm-common/pull/184

[akva2]

with https://github.com/Ensembles/ert/pull/1272 and the just-rewritten https://github.com/OPM/opm-common/pull/184 i have built with c++14 up to opm-grid. there it buggers out on my dune version (2.4) not compiling with c++14, so i can't test further.

[berndflemisch]

I can confirm that with Ensembles/ert#1272, OPM/opm-common#184 and OPM/opm-parser#940, flags for c++14 are set correctly and building succeeds until opm-grid. Thank you!

opm-grid still uses EntityPointer which is gone in Dune 2.5. But that should be treated as a separate issue.

[berndflemisch]

The only drawback was that I had to set manually -DHAVE_DUNE_COMMON=1 for opm-material and -DHAVE_DUNE_GRID=1 for opm-grid, while there seems to be a proper test for HAVE_DUNE_ISTL.

[akva2]

please consult / share CMakeFiles/CMakeError.log

[berndflemisch]

Can't reproduce, please forget my last comment.

[berndflemisch]

So Atgeirr's approach works for me: I keep Opm and Dune in separate directories, build Opm with CMake only and Dune with dunecontrol. No more patching needed for me, thank you.

What remains is that I have to manually specify opm...PREFIX for each Opm module, it is not sufficient to add my Opm installation directory to the CMAKE_PREFIX_PATH. I can live with this behavior, so feel free to close this. If you want to continue, I can provide output files.

[akva2]

that shouldn't be necessary. are you certain you find_package(opm-common) in your build before finding other opm modules ?

[andlaus]

i have built with c++14 up to opm-grid. there it buggers out on my dune version (2.4) not compiling with c++14, so i can't test further.

does this mean that dune 2.4 must not be compiled with c++-2014 and while at the same time, dune 2.5 requires it? that sounds like a nightmare...

[akva2]

yes, that seems to be the situation.

[berndflemisch]

For me, Dune 2.4 compiles both with c++11 and c++14. Dune 2.5 requires c++14.

[akva2]

then you probably have a higher patch version (2.4.x) than what's in xenial repos. good to know nontheless.