cmake_properties for options

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).

You can use the CACHE_VARIABLES property to get the list of all cache variables, then filter based on the TYPE property (option() variables will always have type BOOL.) For example:

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 :)

Thanks, that’s great :slight_smile: (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.

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:

  # ....

And you can of course whitelist any CMAKE_ variables that you need to make exceptions for.

1 Like

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:


… 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.)

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.