|
Notes |
|
|
(0041014)
|
|
LCID Fire
|
|
2016-05-03 05:35
|
|
|
We see this in on multiple OSes and back even with 3.4. There seems to be some combination where overriding options does not work reliably. |
|
|
|
(0041017)
|
|
Brad King
|
|
2016-05-03 08:14
|
|
Check the value on both the first run of CMake in a new tree and again on a second run when the cache is already populated. There is an unfortunate combination of behaviors that causes the cache entry to override the variable on the first run but not later runs. This is documented for the set() command with the CACHE option:
https://cmake.org/cmake/help/v3.5/command/set.html [^]
"If the cache entry does not exist prior to the call or the FORCE option is given then the cache entry will be set to the given value. Furthermore, any normal variable binding in the current scope will be removed to expose the newly cached value to any immediately following evaluation."
Of course on the second run the cache entry already exists and so no removal of the normal variable is triggered.
In general the safest way to override a cache entry is by setting it as a cache entry. Often when I import a third-party project into a subdirectory and want to set one of its cache options instead of exposing it to the user I'll do something like this:
set( myoption ON CACHE INTERNAL "override subdir value") |
|
|
|
(0041020)
|
|
LCID Fire
|
|
2016-05-03 09:11
|
|
Thanks. That indeed works.
Scary however when I think how often we have done the old method across projects.
Would be really great if there was an option to have CMake complain when there is a non CACHE variable used. |
|
|
|
(0042994)
|
|
Kitware Robot
|
|
2016-06-10 14:29
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|