Skip to content

GitLab

D
dune-common
Open
Opened by Lukas Böger@lukas.boeger

Local DUNE_CONTROL_PATH doesn't prevent CMAKE_MODULE_PATH being populated with globally installed entries

When compiling dune modules in a local directory parallel to globally installed modules, the CMAKE_MODULE_PATH can be configured such that global cmake modules have precedence over local ones, even though DUNE_CONTROL_PATH is exclusively set to local paths and the --only option passes nothing but local modules. This can lead to issues during the configuration for different local/global module versions.

Example: all core modules 2.4.1 and dune-alugrid 2.4.0 installed in /usr. Additionaly a local directory with all core-modules, dune-typetree and dune-pdelab from the current master branch. The following command

DUNE_CONTROL_PATH=$(find `pwd` -name dune.module | tr '\n' ':') ./dune-common/bin/dunecontrol --only=dune-common,dune-localfunctions,dune-pdelab,dune-geometry,dune-typetree,dune-istl,dune-grid configure

fails with the output

Call Stack (most recent call first):
  cmake/modules/DunePdelabMacros.cmake:2 (include)
  [pwd]/dune-common/cmake/modules/DuneMacros.cmake:570 (include)
  [pwd]/dune-common/cmake/modules/DuneMacros.cmake:714
  (dune_process_dependency_macros)
  CMakeLists.txt:23 (dune_project)

CMake Error at /usr/share/dune/cmake/modules/Headercheck.cmake:11
(dune_common_script_dir):
 Unknown CMake command "dune_common_script_dir".
Call Stack (most recent call first):
  [pwd]/dune-common/cmake/modules/DuneMacros.cmake:738
  (setup_headercheck)
  CMakeLists.txt:23 (dune_project)

where obviously /usr/share/dune/cmake/modules/Headercheck.cmake has been loaded instead of the local ./dune-common/cmake/modules/Headercheck.cmake though no global directories are involved.

This mechanism can apparently also appear with global, non-DUNE components involved in the compilation, like the std library.