Re: [cmake-developers] Tools for handling cross project dependencies
Le 02.10.17 à 18:06, Egor Pugin a écrit : Sorry, maybe I did not understand you correctly, but why do you need some order of 'add_subdirectory'? I am not sure to understand why you are asking this, please let me know if I am off-topic :) I have say libOpenCV, libTIFF and libZ. libTIFF depends on libZ, libOpenCV depends on libTIFF and libZ. libTIFF and libZ are doing some magic, say they compile from source or if those libraries are available from the OS, they just include the system libraries as imported targets. In a project, I would like to link to libOpenCV, I know it depends on libTIFF and libZ, but I do not know if there is any dependencies between those libTIFF and libZ. I know that I should do an add_subdirectory(libOpenCV) and before that, do an add_subdirectory of libTIFF and libZ. Depending on the orders of the add_subdirectory, I would be able to compile or not libTIFF and subsequently libOpenCV. This should work: " add_subdirectory(libZ) add_subdirectory(libTIFF) add_subdirectory(libOpenCV) " and this should not work " add_subdirectory(libTIFF) add_subdirectory(libZ) add_subdirectory(libOpenCV) " (because the declaration of the libTIFF targets make implicit reference to headers and shared/static library of libZ.) So in a "superproject" (the one that is making the 3 calls to add_subdirectory above), there is an implicit orchestration/ordering of the add_subdirectory commands, and I would somehow like to encode this within CMake and without any other tool. Of course, in this very naive and simplified example, it is easy to address, but this does not scale up efficiently. Somehow, there is a need to encode the graph of dependencies, and to inject that graph into CMake. This is what I suggest to do: discuss about the interest and the "protocol" for encoding such a graph, and what type of information which should carry in the graph (nodes and arrows). Cppan knows from config (yaml) files what deps must be included and just adds them one by one. If they're already in the tree, include guard prevents second use. Right, but there is also an explicit order in your YAML files, isn't it? I have to say I have not look very deeply. One rule is not to have cyclic deps. Yes, the dependencies should form a Directed Acyclic Graph, otherwise we have troubles. This can be checked also very easily. In summary (correct me if I am wrong) what this does is (in some pseudo code): Correct pseudo code for cppan: --- if (TARGET t1) return include(d1) # include file has i. guard include(d2) # cannot use add_subdirectory directly ... declare t1 target_deps t1 d1 d2 ... --- Also in a more complicated settings, you can certainly have the targets defined by d1/d2 sourced by another CMakeLists.txt (say libZ used for target t1=OpenCV and target t2=libYAML, those being on different CMakeLists.txt). You address this by adding an include guard. As a matter of facts, include guards are inducing a topological sort on the order of the targets declaration (roughly speaking "include guards=an implementation of topological sort"). Having access to the dependency graph is however providing a richer information and ease of maintenance, and I am pretty sure this can find many different use cases (outside of mine of course). For example: * being agnostic to the overall directory layout: in your example you only care about the targets d1/d2 being declared, not the file/location of their declaration (while the include directive enforces some directory layout) * detect cyclic dependencies * easy filtering of include or add_subdirectory calls, based on the selection of specific targets (only the direct and indirect parents of the selected target are included in the project, which is easy to do if we have access to the dependency graph) * generated installation package dependency declaration (the debian packages extract the direct dependencies from this graph) * etc... I hope I clarified better the problems I am trying to address, Best, Raffi On 2 October 2017 at 16:10, Raffi Enficiaud wrote: Le 27.09.17 à 19:10, Egor Pugin a écrit : The idea is to include several "packages" (one package ~ one project in Boost) and make those available to the build, exactly as for a regular CMakeLists.txt that adds several directories or subprojects through a sequence of calls to "add_directories". However, the difference here is that "packages" have inter-dependencies, and the order of the "add_directories" should honor those dependencies. I solved the issue of including several dirs (via 'add_directories') using guards 'if (TARGET name); return(); endif()' in my pkg manager. See boost libraries there: https://cppan.org/search?q=boost Each library can be included to project separately with autoincluding required deps for it. Hi, Thank you for your answer. What you did with CPAN is wonderful, but I think this much more than what my humble
Re: [cmake-developers] CMP0071
On Montag, 2. Oktober 2017 06:58:31 CEST Brad King wrote: > On 09/26/2017 12:55 PM, clin...@elemtech.com wrote: > > https://bugreports.qt.io/browse/QTBUG-63442 > > Please take a look at the proposed fix: > > https://codereview.qt-project.org/#/c/207327/ I dropped a few comments. -Sebastian -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tools for handling cross project dependencies
Sorry, maybe I did not understand you correctly, but why do you need some order of 'add_subdirectory'? Cppan knows from config (yaml) files what deps must be included and just adds them one by one. If they're already in the tree, include guard prevents second use. One rule is not to have cyclic deps. > In summary (correct me if I am wrong) what this does is (in some pseudo code): Correct pseudo code for cppan: --- if (TARGET t1) return include(d1) # include file has i. guard include(d2) # cannot use add_subdirectory directly ... declare t1 target_deps t1 d1 d2 ... --- On 2 October 2017 at 16:10, Raffi Enficiaud wrote: > Le 27.09.17 à 19:10, Egor Pugin a écrit : >>> >>> The idea is to include several "packages" (one package ~ one project in >>> Boost) and make those available to the build, exactly as for a regular >>> CMakeLists.txt that adds several directories or subprojects through a >>> sequence of calls to "add_directories". >>> However, the difference here is that "packages" have inter-dependencies, >>> and the order of the "add_directories" should honor those dependencies. >> >> >> I solved the issue of including several dirs (via 'add_directories') >> using guards 'if (TARGET name); return(); endif()' in my pkg manager. >> See boost libraries there: https://cppan.org/search?q=boost >> Each library can be included to project separately with autoincluding >> required deps for it. > > > Hi, > > Thank you for your answer. What you did with CPAN is wonderful, but I think > this much more than what my humble scripts are trying to address. > > Also the guard mechanism does not really address the issue of ordering the > add_directories in some topological order. In particular, you guard because > you do not want to declare several times the same target, but it does not > tell when to include any other dependencies your target may have. > > In summary (correct me if I am wrong) what this does is (in some pseudo > code): > > - > if(target1, target2 ... already defined) > return > > declare target1, target2 ... > target_dependencies target1, target1.1, target1.2 ... > target_dependencies target2, target2.1, target2.2 ... > - > > but it does not tell when to declare target1.1, target1.2 ... and this > knowledge should be encoded somewhere else in your scripts. > > Best, > Raffi > > > > -- > > 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: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Egor Pugin -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 3.10 feature freeze on 2017-10-02
On 09/12/2017 11:53 AM, Brad King wrote: > The feature freeze in 'master' for CMake 3.10 will be on Oct 2, 2017. > I may announce a freeze in 'stage' sometime in the preceding week so > that we can get any remaining dashboard trouble cleaned up. In order to get 'master' ready to branch for 3.10, 'stage' is now frozen to new features. After 3.10 is branched I'll announce when post-3.10 development is open. Meanwhile the following types of changes are still welcome: * Documentation updates * Regression fixes * Dashboard fixes * Fixes for bugs in features new to 3.10 or 3.9 * A few specific changes that I will handle staging. Thanks, -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tools for handling cross project dependencies
Le 27.09.17 à 19:10, Egor Pugin a écrit : The idea is to include several "packages" (one package ~ one project in Boost) and make those available to the build, exactly as for a regular CMakeLists.txt that adds several directories or subprojects through a sequence of calls to "add_directories". However, the difference here is that "packages" have inter-dependencies, and the order of the "add_directories" should honor those dependencies. I solved the issue of including several dirs (via 'add_directories') using guards 'if (TARGET name); return(); endif()' in my pkg manager. See boost libraries there: https://cppan.org/search?q=boost Each library can be included to project separately with autoincluding required deps for it. Hi, Thank you for your answer. What you did with CPAN is wonderful, but I think this much more than what my humble scripts are trying to address. Also the guard mechanism does not really address the issue of ordering the add_directories in some topological order. In particular, you guard because you do not want to declare several times the same target, but it does not tell when to include any other dependencies your target may have. In summary (correct me if I am wrong) what this does is (in some pseudo code): - if(target1, target2 ... already defined) return declare target1, target2 ... target_dependencies target1, target1.1, target1.2 ... target_dependencies target2, target2.1, target2.2 ... - but it does not tell when to declare target1.1, target1.2 ... and this knowledge should be encoded somewhere else in your scripts. Best, Raffi -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extending XCode scheme generation support
Hello Steven, On 9/22/17 3:36 AM, Steven Velez wrote: > # Property-Centric > In this proposal, the generation of the scheme files is customized primarily > by > a user setting additional, specialized properties on a given target, which > then > affect the generation of the scheme files associated with that target. thank you for working an the scheme proposal. I also believe that the property-centric approach is better suited and easier to implement than the file-centrix one. Next steps would be to sequence the necessary changes and define test cases. I could imagine that adding generator-expression support would be much harder to implement that other things. Things that also should be considered are: * differences between macOS and iOS when generating a scheme * what should happen if two targets specify the same schema name Thanks, Gregor -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags?
On 10/02/2017 07:24 AM, Nikola Smiljanic wrote: > Thanks Brad, so setting CXX_EXTENSIONS to off will switch me to > 'standard' compliant mode? Yes. It can be done for all targets on creation by using the CMAKE_CXX_EXTENSIONS variable: https://cmake.org/cmake/help/v3.9/variable/CMAKE_CXX_EXTENSIONS.html -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags?
Thanks Brad, so setting CXX_EXTENSIONS to off will switch me to 'standard' compliant mode? On Mon, Oct 2, 2017 at 10:01 PM, Brad King wrote: > On 10/01/2017 08:29 PM, Nikola Smiljanic wrote: > > I'd like to know why CMake uses 'gnu' flags when setting C++ standard. > > I find this very surprising as 'gnu' mode enables non standard > extensions? > > Setting the standard level should not affect the extensions, and the > compiler's > default mode includes extensions. There is a separate property for > extensions: > > https://cmake.org/cmake/help/v3.9/prop_tgt/CXX_EXTENSIONS.html > > It is ON by default since most compilers have extensions on by default. > > -Brad > -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags?
On 10/01/2017 08:29 PM, Nikola Smiljanic wrote: > I'd like to know why CMake uses 'gnu' flags when setting C++ standard. > I find this very surprising as 'gnu' mode enables non standard extensions? Setting the standard level should not affect the extensions, and the compiler's default mode includes extensions. There is a separate property for extensions: https://cmake.org/cmake/help/v3.9/prop_tgt/CXX_EXTENSIONS.html It is ON by default since most compilers have extensions on by default. -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0071
On 09/26/2017 12:55 PM, clin...@elemtech.com wrote: > https://bugreports.qt.io/browse/QTBUG-63442 Please take a look at the proposed fix: https://codereview.qt-project.org/#/c/207327/ Thanks, -Brad -- 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: http://public.kitware.com/mailman/listinfo/cmake-developers
