Re: [CMake] [proposal] Support for modern CMake
On 22 March 2018 at 16:51, Brad King wrote: > On 03/22/2018 10:17 AM, Mateusz Loskot wrote: >> It seems folks generally agree there is need for porcelain API. >> It's a pity it's been 5+ years and it is still waiting for implementation. > > [...] > The main driving factor was compatibility with existing projects > using `target_link_libraries` at the time. I could have an argument to that... > In the end it was decided that the extra command would be redundant and > we proceeded with `tll()` only. I'd prefer not to have this debated > endlessly again. ...but I won't and I'll shut up then. Thank you for chiming in with the extra details. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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
Re: [CMake] [proposal] Support for modern CMake
On 03/22/2018 10:17 AM, Mateusz Loskot wrote: > It seems folks generally agree there is need for porcelain API. > It's a pity it's been 5+ years and it is still waiting for implementation. For reference, there were several discussions. Some of them were here: * "Setting include directories via target_link_libraries" https://cmake.org/pipermail/cmake-developers/2012-December/017561.html * "Setting includes, defines and other usage requirements with one command" https://cmake.org/pipermail/cmake-developers/2013-January/017939.html It was an extended debate over whether a separate `target_use_targets` command should be introduced instead of propagating usage requirements through `target_link_libraries`. The main driving factor was compatibility with existing projects using `target_link_libraries` at the time. In the end it was decided that the extra command would be redundant and we proceeded with `tll()` only. I'd prefer not to have this debated endlessly again. Perhaps the name `target_link_libraries` no longer fully conveys the semantics, but it's good enough and has worked well for years now. -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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [proposal] Support for modern CMake
On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and, actually read and understand what I'm doing? >> >> (If you're now typing "why don't you create a custom macro wrapper" >> response, please don't!) >> >> How nicely it would fit into the concept of CMake member functions >> presented by Daniel [1] (@17:25 min), wouldn't it? >> >> >> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] >> use_targets(app Boost::system) > > Not sure, I guess I was earlier ;-) > You may want to have a look at > https://cmake.org/pipermail/cmake-developers/2012-December/017561.html > and the following discussion. It seems folks generally agree there is need for porcelain API. It's a pity it's been 5+ years and it is still waiting for implementation. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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
Re: [CMake] [proposal] Support for modern CMake
On 20 March 2018 at 21:52, Alexander Neundorf wrote: > On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: > ... >> Why I can not write: >> >> target_use(app Boost::system Boost::filesystem) >> >> or >> >> target_use_targets(app Boost::system Boost::filesystem) >> >> and, actually read and understand what I'm doing? >> >> (If you're now typing "why don't you create a custom macro wrapper" >> response, please don't!) >> >> How nicely it would fit into the concept of CMake member functions >> presented by Daniel [1] (@17:25 min), wouldn't it? >> >> >> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] >> use_targets(app Boost::system) > > Not sure, I guess I was earlier ;-) Alex, please accept my apologies. I should have used s/Originally/I've learned about/ :) > You may want to have a look at > https://cmake.org/pipermail/cmake-developers/2012-December/017561.html > and the following discussion. I'm eager to have a look, thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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
Re: [CMake] [proposal] Support for modern CMake
On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote: ... > Why I can not write: > > target_use(app Boost::system Boost::filesystem) > > or > > target_use_targets(app Boost::system Boost::filesystem) > > and, actually read and understand what I'm doing? > > (If you're now typing "why don't you create a custom macro wrapper" > response, please don't!) > > How nicely it would fit into the concept of CMake member functions > presented by Daniel [1] (@17:25 min), wouldn't it? > > > Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] > use_targets(app Boost::system) Not sure, I guess I was earlier ;-) You may want to have a look at https://cmake.org/pipermail/cmake-developers/2012-December/017561.html and the following discussion. Alex -- 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
[CMake] [proposal] Support for modern CMake
Hi, I've used CMake for a 10+ years now. I'm not a newbie, but I still discover CMake awesomeness as well as its traps. Now, I'm trying to catch up with the modern CMake party and I obviously watched the famous Daniel Pfeifer's lecture [1] (I'm late, I know!) I asked a simple question on #cmake at cpplang.slack.com: Given add_executable(app app.cpp) target_link_libraries(app PRIVATE Boost::filesystem) Is that correct to expect the myapp target is also configured with all the corresponding ***include*** directories (ie. Boost headers location)? Or, do I need to call anything else, like: target_include_directories(app PRIVATE Boost::boost) Then, I realised that the current CMake API is does not follow its own evolution that happened recently leaving lots of room for semantical ambiguity. In the 'old school' CMake, I would write: target_link_libraries(app ${Boost_LIBRARIES}) target_include_directories(app ${Boost_INCLUDE_DIRS}) All is clear and explicit. In the modern CMake, I write: target_link_libraries(app Boost::system) Is all equally clear here? No! Why CMake does not follow its own evolution and does not update its API with **new** commands to support the modern CMake? Why I can not write: target_use(app Boost::system Boost::filesystem) or target_use_targets(app Boost::system Boost::filesystem) and, actually read and understand what I'm doing? (If you're now typing "why don't you create a custom macro wrapper" response, please don't!) How nicely it would fit into the concept of CMake member functions presented by Daniel [1] (@17:25 min), wouldn't it? Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3] use_targets(app Boost::system) and I just renamed it to fit in the Daniel's concept of looking at CMake API as OOP, that is OOP like in C in GTK+ :), of course. [1] https://twitter.com/mloskot/status/973914895287713793 [2] https://github.com/vector-of-bool/vscode-cmake-tools [3] https://cpplang.slack.com/archives/C5Y2GDECX/p152122705490 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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