[cmake-developers] Setting includes, defines and other usage requirements with one command

[David Cole]

On Jan 24, 2013, at 3:00 PM, Stephen Kelly wrote:

> <snip>

> As far as I understand, the only objection is to the idea that 
> target_link_libraries would be doing something other than linking, and it 
> might not be obvious. It is currently used for -fPIC, so I'm not so sure. 
> 
> Also, the objection is not that people would have to learn or discover, in 
> documentation or otherwise, that target_link_libraries could have an effect 
> other than linking. The objection instead is that, even long term and for 
> experienced people, reading a line of code that contains a 
> target_link_libraries call alone would not inform them of whether it is 
> 'only' linking or whether it has other affects. This also seems funny to me. 
> Given a line containing target_use_interfaces(foo PRIVATE bar), it is 
> impossible to know from reading alone whether foo INCLUDE_DIRECTORIES, 
> COMPILE_DEFINITIONS, LINK_LIBRARIES, or all three, are affected by the line. 
> In both cases, the way to know is to use
> -DCMAKE_DEBUG_TARGET_PROPERTIES=INCLUDE_DIRECTORIES or similar.
> 
> </snip>


It's not only that target_link_libraries would be doing more than linking, it's also that you want to change the behavior of something that has existed for 12+ years without this behavior.

If you do re-use target_link_libraries for your glorious "one command to rule them all," just be aware that you are invalidating 12+ years worth of everything ever written about it on the web, and the collective experience of thousands of CMake users around the world.

*That* is my objection to re-purposing the name target_link_libraries, not that you'd be doing more than linking. I don't think it's worth the confusion that might come after this.

I would not object at all to any *new* command with an entirely new name, such that it may be written about anew, with great excitement, now that the one true command is about to be born.


:-)
David