Best practice for configuration-dependent defaults?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for configuration-dependent defaults?

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 <[hidden email]> 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