[CMake] Best practice for configuration-dependent defaults?

2018-08-17 Thread 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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


Re: [CMake] Best practice for configuration-dependent defaults?

2018-08-23 Thread Petr Kmoch
Hi Sam,

it seems to me that your user-facing option is not actually Boolean, but
tri-state: On vs. Off vs. Use_default. So I would represent it accordingly:
present the user with a string variable (with suitable STRINGS property
https://cmake.org/cmake/help/latest/prop_cache/STRINGS.html), and then
control my internal CMake logic like this:

if(FOO STREQUAL "USE_DEFAULT")
  # ...
elseif(FOO)
  # user turned FOO on
else()
  # user turned FOO off
endif()

Petr

On Fri, 17 Aug 2018 at 19:18, Sam Edwards  wrote:

> 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
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake