Re: [CMake] [proposal] Support for modern CMake

[Mateusz Loskot]

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

[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

Re: [CMake] [proposal] Support for modern CMake

[Mateusz Loskot]

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

[Mateusz Loskot]

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

[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

[CMake] [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/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