# cmake\_properties for options
**URL:** https://discourse.cmake.org/t/cmake-properties-for-options/250
**Category:** Code
**Created:** [November 24, 2019, 9:34pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250 "2019-11-24T21:34:39Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@eriols](https://discourse.cmake.org/u/eriols)
#### Post date: [November 24, 2019, 9:34pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250/1 "2019-11-24T21:34:39Z")
Hi, I’d like to have a property that holds all the `option` that are active that I can then query via the `get_cmake_property`. I can get them printed by running cmake with the -L argument but I’d prefer them available through a distinct property too. Is there one that I’m missing or should I submit this as a feature request?
Currently I (and others I have found on the internet) seems forced to implement a macro that always appends the given option to a list, but that is really clunky (I just want the banana, not the whole gorilla holding the banana and the jungle it’s in etc).
Thanks.
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [November 25, 2019, 2:31pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250/2 "2019-11-25T14:31:48Z")
You can use the [`CACHE_VARIABLES`](https://cmake.org/cmake/help/latest/prop_dir/CACHE_VARIABLES.html) property to get the list of all cache variables, then filter based on the [`TYPE`](https://cmake.org/cmake/help/latest/prop_cache/TYPE.html) property (`option()` variables will always have type `BOOL`.) For example:
```cmake
get_property(cache_variables DIRECTORY PROPERTY CACHE_VARIABLES)
foreach(v IN LISTS cache_variables)
get_property(type CACHE ${v} PROPERTY TYPE)
if(type STREQUAL "BOOL")
# Here's your banana without the whole jungle :)
endif()
endforeach()
```
---
### Author:  [@eriols](https://discourse.cmake.org/u/eriols)
#### Post date: [November 25, 2019, 8:13pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250/3 "2019-11-25T20:13:51Z")
Thanks, that’s great 🙂 (the only extra variables compared to saving the options manually are a handful of cmake internal things like `CMAKE_SKIP_RPATH` but that’s a good trade-off.
Thanks again.
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [November 25, 2019, 9:37pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250/4 "2019-11-25T21:37:09Z")
Depending on what you’re trying to do, you might be able to filter out anything that starts with `CMAKE_`, as that prefix is reserved for CMake’s own use:
```cmake
if(type STREQUAL "BOOL" AND NOT v MATCHES "^CMAKE_")
# ....
endif()
```
And you can of course whitelist any `CMAKE_` variables that you need to make exceptions for.
---
### Author:  [@eriols](https://discourse.cmake.org/u/eriols)
#### Post date: [December 8, 2019, 7:46pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250/5 "2019-12-08T19:46:23Z")
Thanks, that was very helpful.
Sorry for coming back to this somewhat late but I noticed another related potential strangeness:
When using the CMAKE\_DEPENDENT\_OPTION macro and ending up in the fallback condition the option in question does not get added to the CACHE\_VARIABLES. Eg when having this for a Release build and the option not specified on the command line:
```auto
CMAKE_DEPENDENT_OPTION(WITH_VERBOSE_LOGGING "Enables all log levels "
ON "CMAKE_BUILD_TYPE STREQUAL Debug OR WITH_VERBOSE_LOGGING" OFF)
```
… the WITH\_VERBOSE\_LOGGING option is not to be found among the CACHE\_VARIABLES. I would have expected it to be there with the value OFF.
(Maybe I’m abusing this macro - I need to have the OR there as it otherwise ignores user input which should take precedence over the build type here.)
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 15, 2020, 10:52pm UTC](https://discourse.cmake.org/t/cmake-properties-for-options/250/6 "2020-02-15T22:52:53Z")
I believe that `cmake_dependent_option` is lazy in making a public cache variable. That is, if the condition guard has never been true, it just sets the local fallback variable value and never makes the cache variable in the first place.
Though in your specific instance, you’re having your dependent option depend directly on itself. I don’t think that is what you actually mean (just doing the build type comparison would be better). Though you’re also not supporting multi-config generators by using `CMAKE_BUILD_TYPE` here either, but that might be OK in your project.