Hello Cornelis,
I'm not sure if I get your use-case completely, but somtimes I also have the
need for three-state variables. What I usually do:
set(MY_OPTION "AUTO" CACHE STRING "Documentation for my option")
set_property(CACHE MY_OPTION STRINGS "ON:OFF:AUTO")
if("${MY_OPTION}" STREQUAL AUTO)
# not set
else()
if (MY_OPTION)
# on
else()
# off
endif()
endif()
Cheers,
Johannes
On Montag, 11. Juni 2018 10:55:50 CEST Cornelis Bockemühl wrote:
> Thanks for your proposals!
> Actually my problem is basically that I want to keep up with some
> minimum good practice, but I am seeing myself throwing it over board
> constantly if I do not find a logical solution after one or two hours
> of struggling...
> Your second option is close to what I am currently implementing -
> basically just hard-code the option into the sub-project and let the
> user adapt the CMakeLists.txt before starting cmake. A bit "brute
> force", not nice, certainly not "good practice" - but works!
> However, what I imagine is rather like this - from a user perspective:
> - if the user goes into the main project with cmake-gui, he will see
> THAT_OPTION with a default value and of course the option to change it.
> In this case, the sub-project should be built without further bothering
> the user with options - just take it from the main project. The point
> is that the option will have an effect for both the main and the sub
> project, but it has to be the same in both.
> - if the user goes directly into the sub project with cmake-gui, he
> should also see THAT_OPTION, but now it would come from the
> CMakeLists.txt of the sub project. Again with a default value and the
> option to change it.
> My guess is that I would need an additional "flag" variable that tells
> the sub project whether it is now being built within the main project
> or standalone. Again not so nice, but besides the "brute force
> solution" (hardcoded) the only one that I can see to do it more
> nicely...
> Regards,Cornelis
>
> Am Montag, den 11.06.2018, 10:44 +0200 schrieb Andreas Naumann:
> > Dear Cornelis,
> >
> >
> >
> > your description looks to me like having a three valued option: ON,
> > OFF, UNDEFINED. But an option in cmake language has only two values:
> > ON or OFF.
> >
> > To solve your problem with the connection between your sub-project
> > and the main project, you should forget about the main project and
> > concentrate on the sub project only. Than, you have two
> > possibilities:
> >
> > 1) Keep the three state variable "THAT_OPTION". Set it to
> > undefined at the very beginning and check later with if(DEFINED
> > THAT_OPTION) .... With this variant, you can handle the "I forgot to
> > set it"-case. But your user will not see it as an option in the cmake
> > gui. Your main project will set it, as desired.
> >
> > 2) Use an initial value for the option. Now, it is always
> > defined, there is no need to check for the source. It is the
> > responsibility of the user to set the option appropriately.
> >
> >
> >
> > I think, the second version is the easiest way.
> >
> >
> >
> > Regards,
> >
> > Andreas
> >
> >
> >
> > Gesendet: Montag, 11. Juni 2018 um 10:20 Uhr
> >
> > Von: "Cornelis Bockemühl" <corne...@bockemuehl.ch>
> >
> > An: cmake@cmake.org
> >
> > Betreff: [CMake] conditions and included subprojects
> >
> >
> > Dear CMake users,
> >
> >
> >
> >
> >
> > Maybe my question is trivial for most, but still I do not find an
> > answer on my own!
> >
> >
> >
> >
> >
> > If you have a project and some sub-project (or module or whatever the
> > jargon is) that are both managed with CMake, they should be in
> > separate directories (directory trees), and each of them have a
> > CMakeLists.txt in the root directory, where the sub-project is
> > "included" into the main project with an ADD_DIRECTORY() etc. So far
> > so clear.
> >
> >
> >
> >
> >
> > But then I learned that it is good practice to ensure that the sub-
> > project would also be "buildable" with cmake separately. My problem
> > is about how to pass options from the main to the sub project in such
> > a way that this is working properly, i.e.:
> >
> >
> >
> >
> >
> > - if the sub project is part of the main project it would simply take
> > over the option from the main project level
> >
> >
> > - but if the sub project is being built standalone, the option is not
> > defined and should be set e.g. in cmake-gui
> >
> >
> >
> >
> >
> > If I write now in the sub project
> >
> >
> >
> >
> >
> > IF(THAT_OPTION)
> >
> >
> > ...
> >
> >
> >
> >
> >
> > this will be true if THAT_OPTION was set to ON in the main project.
> > So far so good. But the expression is now so "clever" that it cannot
> > distinguish between THAT_OPTION being set to OFF in the main project,
> > or THAT_OPTION not being defined at all - like in a standalone build!
> >
> >
> >
> >
> >
> > One way would be to have an additional option or variable
> > BUILDING_MAINPROJECT which is set to ON or TRUE in the main project
> > and can be checked. However, I have so far not seen any
> > CMakeLists.txt with such a code, so ... what are the experts doing in
> > such a case?
> >
> >
> >
> >
> >
> > Thanks and regards,
> >
> >
> > Cornelis
> >
> >
> >
> >
> > -- 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
--
Johannes Zarl-Zierl
Information management
JOHANNES KEPLER UNIVERSITY LINZ
Altenberger Straße 69
4040 Linz, Austria
P +43 732 2468 3898
johannes.zarl-zi...@jku.at
www.jku.at
--
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
