#1686 [cmake] Building local modules against installed dune-common results in wrong CMAKE_MODULE_PATH
Metadata
Property | Value |
---|---|
Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
Reported at | Jul 3, 2015 15:32 |
Type | Bug Report |
Version | 2.3 |
Operating System | Unspecified / All |
Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
Last edited at | Jul 10, 2015 13:24 |
Closed by | Carsten Gräser (graeser@math.fu-berlin.de) |
Closed at | Jul 10, 2015 13:24 |
Closed in version | Unknown |
Resolution | Fixed |
Comment | Fixed in master, merged to 2.4. |
|
Description
Dear list,
Building a local dune module against an installed dune-common could fail with a cmake error, if the local module introduced some build system changes. Here is what happens:
The standard module-root CMakeLists.txt contains the following line: list(APPEND CMAKE_MODULE_PATH ${dune-common_MODULE_PATH} "${PROJECT_SOURCE_DIR}/cmake/modules")
However, the structure of our installs is such, that all cmake macros from all modules end up in the same directory. Consequently, adding dune-common_MODULE_PATH for an installed module adds a path, where modules for ALL installed modules can be found. The order within the path variables favors installed versions over local ones. You end up with a local module that uses the cmake modules directory from an installed pdelab, which of course might be incompatible.
Proposed Solution: Reverse the order of directories in CMAKE_MODULE_PATH: always prepend, instead of append. That way, all upstream modules end up at the end of the path variable.
Thanks Oli for reporting.