[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/p1521227050000490

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net