Why are BOOL cache variables sometimes used instead of options?
envgap__RainerKuemmerle__g2o-630
01 / FAILURE SIGNATURE
As reported upstream
No identifying execution failure has been captured.
Not a benchmark task.
- In a clean container the reported failure did not reproduce, or the known fix did not make the project run.
02 / ENVIRONMENT RECIPE
- Base commit
5212e0a2c6c12c3db449e570632aa36f08966b8b- Manifest
CMakeLists.txt- Reproduce
Awaiting issue-specific recipe- Run under trace
Awaiting a meaningful runtime command
03 / ORIGINAL ISSUE TEXT
RainerKuemmerle/g2o #630 · read the original issue
In the main CMake file some configurational variables are set with `option()` while some are set as BOOL cache variables (`G2O_BUILD_APPS` and `G2O_BUILD_EXAMPLES` for example). Is there a reason for this? I am asking because even these ways of setting variables have similar functionality, there are subtle differences in the behavior of `set(CACHE)` and `option()` commands. The one that is important to me is that when `option()` is used, it can be overridden with a non-cache variable (see [CMP0077](https://cmake.org/cmake/help/latest/policy/CMP0077.html)), while `set(CACHE)` can only be overridden with cache variables (seems like it is true until CMake 3.22, see [CMP0126](https://cmake.org/cmake/help/latest/policy/CMP0126.html#policy:CMP0126)) which are visible to users until `INTERNAL` is used. This is not a big deal, just the resulting code becomes less compact. If there is no particular reason, I would suggest using `option()`.
04 / LABELS
Labels from the report text only; not yet run
No supported category has been assigned.
Label rules and the text that matched
[]