Re: [CMake] conditions and included subprojects
I think, I missunderstood some parts. In particular, why should the user have to change the CMakeLists.txt? He/she can set the value at the commandline or in the cmake-gui and your CMakelist sees the value of your option and can react to that. Gesendet: Montag, 11. Juni 2018 um 10:55 Uhr Von: "Cornelis Bockemühl" An: "Andreas Naumann" , cmake@cmake.org Betreff: Re: [CMake] conditions and included subprojects 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" 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 commu
Re: [CMake] conditions and included subprojects
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"
> >
> > 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
> >
Re: [CMake] conditions and included subprojects
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" > > 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
Re: [CMake] conditions and included subprojects
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" 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 -- 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
