-
Markus Blatt authored
Previously we relied on CMake's export(PACKAGE ...) function when finding dune packages without dune-control. This is error prone when using several instances of a dune-module (either with differing versions or built using different options). In this case there is no control which of the instances is used. Now we try to guess the correct build directory, if it was not provided with ${module}_DIR, ${module}_Root or in the CMAKE_PREFIX_PATH. Note that when using dunecontrol ${module}_DIR will always be set. We take the path of the current toplevel build directory and simply substitute any occurence of the name of current module with name of the module that we try to find. This works for both building in a subdirectory of the source tree (e.g. ${module-source}/build-cmake) or in a sibling directory
Markus Blatt authoredPreviously we relied on CMake's export(PACKAGE ...) function when finding dune packages without dune-control. This is error prone when using several instances of a dune-module (either with differing versions or built using different options). In this case there is no control which of the instances is used. Now we try to guess the correct build directory, if it was not provided with ${module}_DIR, ${module}_Root or in the CMAKE_PREFIX_PATH. Note that when using dunecontrol ${module}_DIR will always be set. We take the path of the current toplevel build directory and simply substitute any occurence of the name of current module with name of the module that we try to find. This works for both building in a subdirectory of the source tree (e.g. ${module-source}/build-cmake) or in a sibling directory