[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] Best practice for configuration-dependent defaults?
From: Petr Kmoch <petr.kmoch () gmail ! com>
Date: 2018-08-24 6:29:31
Message-ID: CAKohaZf5d_ke+p1RXBGE+e2zxP0E+kO6G4ST=GTN-mOBCFpaCQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <cfsworks@gmail.com> 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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>Hi Sam,</div><div><br></div><div>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 <a \
href="https://cmake.org/cmake/help/latest/prop_cache/STRINGS.html">https://cmake.org/cmake/help/latest/prop_cache/STRINGS.html</a>), \
and then control my internal CMake logic like this:</div><div><br></div><div>if(FOO \
STREQUAL "USE_DEFAULT")</div><div> # \
...<br></div><div>elseif(FOO)</div><div> # user turned FOO \
on</div><div>else()</div><div> # user turned FOO \
off</div><div>endif()<br></div><div><br></div><div>Petr<br></div></div><br><div \
class="gmail_quote"><div dir="ltr">On Fri, 17 Aug 2018 at 19:18, Sam Edwards <<a \
href="mailto:cfsworks@gmail.com">cfsworks@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi \
all!<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><div>option(FOO "This is foo" \
ON)</div><div>message("FOO is ${FOO}")</div><div>option(FOO "This is \
foo" OFF)</div><div>message("FOO is \
${FOO}")</div></div><div><br></div><div>...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.</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Sam</div></div>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" \
target="_blank">www.kitware.com</a><br> <br>
Please keep messages on-topic and check the CMake FAQ at: <a \
href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" \
target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br> <br>
Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:<br> <br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" \
target="_blank">http://cmake.org/cmake/help/support.html</a><br> CMake Consulting: <a \
href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" \
target="_blank">http://cmake.org/cmake/help/consulting.html</a><br> CMake Training \
Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" \
target="_blank">http://cmake.org/cmake/help/training.html</a><br> <br>
Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" \
target="_blank">http://www.kitware.com/opensource/opensource.html</a><br> <br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" \
target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br> </blockquote></div>
--
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic