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.