[CMake] conditions and included subprojects

Mon Jun 11 04:55:50 EDT 2018

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" <cornelis at bockemuehl.ch>
> 
> An: cmake at 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
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180611/2c24b04c/attachment-0001.html>