#1670 cmake caching is too aggressive
Metadata
Property | Value |
---|---|
Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
Reported at | Jun 17, 2015 08:30 |
Type | Bug Report |
Version | Git (pre2.4) [cmake] |
Operating System | Unspecified / All |
Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
Last edited at | Sep 25, 2015 14:35 |
Description
The cmake caching is too aggressive and by this causes many problems. In particular cmake doesn't always realize if the configuration in the opts file, or the configuration of a dependency changes. A common problem was e.g. that cmake didn't realize changes in the cmake scripts of dependencies.
In feature/cleanup-cmake-on-configure I have pushed a proposed solution.
The patch assumes that calling "dunecontrol configure" is an explicit statement by the user that he wants a reconfiguration. Thus we remove (upon calling configure) all cmake cache files and by this forces a full reconfiguration. The downside is that this increases the amount compilation.
I discussed this with Dominik when I was in HD the last time and we tried a couple of other solution, but in my experience this is the only reliable way. Usually the proposed solution was to remove the build directory, which will even more increase the amount of recompilation.
I'd like to have a solution in 2.4, was we now want to push the users to use cmake. When updating old modules, many users might encounter similar problems and with this patch we slightly reduce the amount of support questions.