[proposal] Support for modern CMake

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[proposal] Support for modern CMake

Mateusz Loskot
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/p1521227050000490

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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] Support for modern CMake

Alexander Neundorf
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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] Support for modern CMake

Mateusz Loskot
On 20 March 2018 at 21:52, Alexander Neundorf <[hidden email]> 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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] Support for modern CMake

Mateusz Loskot
In reply to this post by Alexander Neundorf
On 20 March 2018 at 21:52, Alexander Neundorf <[hidden email]> 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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] Support for modern CMake

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: [proposal] Support for modern CMake

Mateusz Loskot
On 22 March 2018 at 16:51, Brad King <[hidden email]> 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
--
Mateusz Loskot
http://mateusz.loskot.net