# Incremental build bug? Changing project option default isn't registering on incremental builds.
**URL:** https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695
**Category:** Usage
**Tags:** os:linux, os:windows
**Created:** [February 24, 2020, 7:44pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695 "2020-02-24T19:44:37Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [February 24, 2020, 7:44pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/1 "2020-02-24T19:44:37Z")
Here is a link to a public repository to show the problem:
> **[YMba9g8j9CJp0wLoQf5y/cmake\_default\_option\_issue](https://github.com/YMba9g8j9CJp0wLoQf5y/cmake_default_option_issue)**
>
> By default cmake options do not support incremental builds. If a component A imports component B and B defines an option (say FOO) that A does not explicitly set, any change (in B) of the default v...
The instructions are in the readme.md but I’ll repeat them here:
cmake\_default\_option\_issue
By default cmake options do not support incremental builds. If a component A imports component B and B defines an option (say FOO) that A does not explicitly set, any change (in B) of the default value of FOO will be silently ignored by cmake (when doing incremental builds). With the config helper the incremental build will fail, which is still not good but better than silently producing bad binaries.
How to reproduce:
```
Run cmake and build normally. Run the executable and see this message.
.\A.exe FOO = ON
In B/CMakeLists.txt change the default for FOO from ON to OFF (o vice versa)
Do an incremental build. The change from step 2. is ignored. Cmake re-runs but nothing is rebuilt
.\A.exe FOO = ON
```
---
### Author:  [@fdk17](https://discourse.cmake.org/u/fdk17)
#### Post date: [February 25, 2020, 4:50am UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/2 "2020-02-25T04:50:00Z")
I’m just going by memory but doesn’t the “option” command add the variable into the cache?
Then subsequent uses of “option” are ignored as it’s already present in the cache.
You would then have to explicitly set the option value you want as the new default is ignored.
Refer to CMP0077 and the option command.
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [February 25, 2020, 4:44pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/3 "2020-02-25T16:44:01Z")
You are correct
option(foo “Documentation” ON)
is the same as
set(foo ON CACHE BOOL “Documentation”)
* * *
But I was hoping to point out that this behavior might not be desirable for projects.
And or is non-obvious.
Because if I absorb a project that is for example defaulting an option to be off since it is experimental code. Then after being fully tested they change the default to be on. Then I don’t get the new default.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 28, 2020, 9:53am UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/4 "2020-02-28T09:53:16Z")
If you want your project to follow the default options, then you need to delete those options from the cache (and any other cache variables that might depend on them) and re-run CMake. This will result in the new defaults being picked up. Look into the `-U` option of the `cmake` command line tool, or you can select which variables to remove from the cache interactively if using `ccmake` or the CMake GUI application.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 28, 2020, 8:13pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/5 "2020-02-28T20:13:20Z")
This issue is related to what you want: [https://gitlab.kitware.com/cmake/cmake/issues/14756](https://gitlab.kitware.com/cmake/cmake/issues/14756)
There’s another to have an explicit default feature for cache variables. This is emulated in VTK and ParaView in a few places. [https://gitlab.kitware.com/vtk/vtk/blob/76d9b339869fef2241bcf7d2310cddda12916799/CMakeLists.txt#L298](https://gitlab.kitware.com/vtk/vtk/blob/76d9b339869fef2241bcf7d2310cddda12916799/CMakeLists.txt#L298)
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 3, 2020, 6:43pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/6 "2020-03-03T18:43:23Z")
Thanks Ben the VTK link hit the point exactly!
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 3, 2020, 6:50pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/7 "2020-03-03T18:50:19Z")
Would it make sense to create a generic cmake module that encapsulates what VTK is doing?
include (option\_default)
option\_default(foo …)
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 3, 2020, 9:12pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/8 "2020-03-03T21:12:02Z")
I wouldn’t mind seeing a module offer such functionality.
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 13, 2020, 6:58pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/9 "2020-03-13T18:58:11Z")
I’ve created and tested an implementation of option\_default() this fixes the issue described in this post.
Feel free to try it and look at the implementation (which is basically an abstraction of the VTK implementation):
>
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 13, 2020, 10:28pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/10 "2020-03-13T22:28:00Z")
You might want to also take in another `TYPE` parameter. Having `option` end up with a `STRING` variable seems…odd as well. And `mark_as_advanced` should also be left to the caller to decide. I’m also a chronic quoter in CMake 🙂 .
```cmake
function(set_with_default variable help_text type value)
set("${variable}" "" CACHE "${type}" "${help_text}")
if (variable STREQUAL "")
set("${variable}" "${value}" PARENT_SCOPE)
endif ()
endfunction ()
```
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 13, 2020, 11:19pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/11 "2020-03-13T23:19:16Z")
100% agree I was mindlessly copying the VTK thank you very much for the feedback 🙂
One note I just tested the function and variable needs to be called with this syntax in order to work ${variable}
```auto
function(set_with_default variable help_text type value)
set("${variable}" "" CACHE "${type}" "${help_text}")
if (${variable} STREQUAL "")
set("${variable}" "${value}" PARENT_SCOPE)
endif ()
endfunction()
```
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 16, 2020, 7:12pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/12 "2020-03-16T19:12:28Z")
Do you think there is enough merit to try and make this a standard module?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 17, 2020, 1:13pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/13 "2020-03-17T13:13:38Z")
I personally think it has enough utility. Even though it is short, it’s another useful tool in the toolbox and a decent convention to have (though bikeshedding over the spelling of `` is possible).
Note that another approach (though it involves a lot more work), is to add a `DEFAULT` property for `CACHE` variables and have CMake do this internally. This approach would also assist with [this issue](https://gitlab.kitware.com/cmake/cmake/issues/14756).
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 19, 2020, 7:45pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/14 "2020-03-19T19:45:19Z")
Either of those options sounds great.
Just to clarify is this what you mean?
```auto
set( ... CACHE [FORCE] [DEFAULT])
option( "" [value] [DEFAULT])
set(foo "Hello" CACHE STRING "good documentation" DEFAULT)
option(bar "..." ON DEFAULT)
```
---
### Author:  [@YMba9g8j9CJp0wLoQf5y](https://discourse.cmake.org/u/YMba9g8j9CJp0wLoQf5y)
#### Post date: [March 19, 2020, 7:47pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/15 "2020-03-19T19:47:36Z")
Or what about this?
```auto
set( ... CACHE [FORCE] [NO_DEFAULT])
option( "" [value] [NO_DEFAULT])
set(foo "Hello" CACHE STRING "good documentation")
option(bar "..." ON)
```
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 19, 2020, 8:03pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/16 "2020-03-19T20:03:11Z")
> [@YMba9g8j9CJp0wLoQf5y](#):
>
> set( … CACHE [FORCE] [DEFAULT])
Something like this _may_ work (I expect there to be design discussions, so I recommend opening an issue and Cc’ing at least me, `@craig.scott` and `@brad.king`). This could work as-if:
```cmake
set( "" ... CACHE [FORCE])
set_property(CACHE PROPERTY DEFAULT )
```
I suppose that CMake will have to do the `` translation at its `cmCacheManager` level to make this work. I don’t know if `FORCE DEFAULT` makes sense either.
> [@YMba9g8j9CJp0wLoQf5y](#):
>
> option(bar “…” ON DEFAULT)
Eh, booleans are harder to do here, so any `option()` support should be considered after we have the groundwork laid out. This is mostly a GUI (and curses) thing though, so maybe not that bad.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [March 29, 2020, 7:17am UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/17 "2020-03-29T07:17:09Z")
Please don’t let this topic die.
A lot of projects I’ve worked on have a **terrible** understanding of cache variables and they think when they update their defaults it will propagate correctly. And of course it doesn’t (unless the user deletes their cache, which people who are new to cmake don’t know to do). This has literally been a roadblock to cmake adoption at my current company.
Resulting in annoyed developers complaining to the build person. Resulting in resistance to using cmake as a build system (from my companies experience).
While setting a property like was mentioned by @ben.boeckel works.
It’s way too advanced for new cmake writers. I think it should be a policy change.
That way we can keep the syntax for set/option. Without adding complexity for people new to cmake.
I don’t think anyone really wants the existing behavior anyway (at least the people I’ve worked with). Also granted everyone I work with is just getting used to the idea of cmake. (Which I think is a perfect argument in my favor, cmake should be intuitive to new users).
And if people really want to use the old behavior then they can set the policy to use the old behavior.
In summary the policy would effectively make option/set do exactly what @YMba9g8j9CJp0wLoQf5y’s **set\_with\_default** does and I think everyone would be happier. I don’t see how this would even hurt existing projects.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [March 29, 2020, 7:19am UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/18 "2020-03-29T07:19:52Z")
Plus making this a policy change would make it so you wouldn’t have to write a CMAKE\_DEPENDENT\_OPTION\_DEFAULT.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 29, 2020, 5:00pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/19 "2020-03-29T17:00:53Z")
> [@anon45792294](#):
>
> While setting a property like was mentioned by @ben.boeckel works.
>
> It’s way too advanced for new cmake writers. I think it should be a policy change.
The problem with any other naive setting is that it becomes indeterminate whether a cache variable that happens to be set to the default has that value because it was left as the default or was explicitly chosen to be that value (in which case, it should not be updated). Whatever new behavior is available, this distinction must be possible. As such, the existing `set()` behavior cannot be sufficient.
> [@anon45792294](#):
>
> And if people really want to use the old behavior then they can set the policy to use the old behavior
That’s not how policies work. Policies are there for backwards compatibility only, not feature behavior selection. A policy says “this is how CMake prefers to work now, but we’re supporting the old behavior until you upgrade”. Setting policies to `OLD` should go away as projects bump minimum CMake versions.
---
### Author:  [@anon45792294](https://discourse.cmake.org/u/anon45792294)
#### Post date: [March 29, 2020, 8:00pm UTC](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695/20 "2020-03-29T20:00:19Z")
That makes sense. What about the suggested syntax above? I feel like it’s much more clear than setting a property.
```auto
set( ... CACHE [FORCE | DEFAULT])
option( "" [value] [DEFAULT])
```
[Next page](https://discourse.cmake.org/t/incremental-build-bug-changing-project-option-default-isnt-registering-on-incremental-builds/695.md?page=2)