[CMake] Best practice for configuration-dependent defaults?

[Sam Edwards]

Hi all!

I have a project with some options that have different defaults depending
on the configuration used to build the project. For example, support for a
certain (easy to support, but relatively uncommon) file format should be on
by default, except when building in the MinSizeRel configuration. Or
inclusion of a certain optional troubleshooting feature should be on by
default only when building for Debug, and should default to off in all
other configurations.

For single-configuration generators, this is pretty easy: I just look at
the CMAKE_BUILD_TYPE variable and switch the option() defaults depending on
the selected build type, then generate my config.h once.

I'm trying to support multi-configuration now. My current plan is to
generate one config.h per build configuration (e.g. include/Debug/config.h,
include/MinSizeRel/config.h, ...) so that the options which the user hasn't
explicitly set can have different per-configuration values depending on
their per-configuration defaults.

However, where I'm getting stuck is in changing the default for an option
and having that default take precedence when the user hasn't overridden the
option explicitly. I can't just do something like:
option(FOO "This is foo" ON)
message("FOO is ${FOO}")
option(FOO "This is foo" OFF)
message("FOO is ${FOO}")

...because the first option(FOO ...) sets it to ON when it sees it isn't in
cache and isn't selected by the user, so the second option(FOO ...) thinks
it's already been set explicitly. Unless there's some way of distinguishing
"ON because it's the default" from "ON because the user explicitly
requested it" while having everything still show up correctly in the GUI,
this won't work.

Is this really the best practice for what I'm trying to do, or is there a
better "CMake way" to do this? How do you folks solve this problem in your
own projects?

Thanks,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180817/b34e9262/attachment.html>