[cmake-developers] Setting include directories via target_link_libraries() ?

[Stephen Kelly]

Alexander Neundorf wrote:
>>  set(Foo_LIBRARIES Foo::importedlib ${Bar_LIBRARIES})
> 
> This shouldn't be necessary, should it ?
> If Foo::importedlib is an exported target created by cmake, there should
> be no need to add additional libraries manually to it, AFAICT.

Maybe, but what if Foo depends on Bing, and Bing depends on Bar, and Foo has 
Bing libraries in its INTERFACE_LINK_LIBRARIES, but Bing doesn't install 
IMPORTED targets.

I'm sure there will be some kind of reason for people to do things like 
this.

>> Or worse, FooConfig.cmake will create IMPORTED targets for Bar (Bad idea,
>> see 5 below)
>> 
>> This is solvable by letting target_use_interfaces also accept library
>> names and library paths, but then the new command is less 'exact' and
>> more redundant.
> 
> 
> It could warn if it detects a normal library...

Why warn? Why not just accept silently? Is it a problem to accept libraries 
or not? Is it possible to detect a normal library? Is that just anything 
which is not a known target? 


>> 2) Inconvenience
>> 
>> Assuming target_use_interfaces only allows targets, you'll have a lot of
>> this:
>> 
>>  tll(foo lib1)
>>  target_use_interfaces(foo lib2)
>>  tll(foo lib3)
>> 
>> instead of just
>> 
>>  tll(foo lib1 lib2 lib3)
> 
> Shouldn't
> 
> target_link_libraries(foo lib1 lib3)
> target_use_interfaces(foo lib2)
> 
> work too ?

It is a different order. If order is relevant, then it's not the same.

> The imported target lib2 should know all its dependencies, right ?

Yes, presumably.
  
>> 8) Non-discoverability
>> 
>> No one will use/benefit from/discover the new feature (with regard to
>> includes and defines) without first explicitly using the new command. No
>> one will discover it accidentally. Maybe we can add a note about it to
>> the tll documentation, but if people are going to read that, then it is
>> just as easy for us to write 'tll also populates includes and defines
>> from its dependencies'.
> 
> Here I disagree.
> You talk about the discoverability of somebody who wants to use this new
> feature.

Yes.

> For me the reading and understanding of an existing CMakeLists.txt is more
> important, i.e. maintaining and debugging, not writing.
> From this POV, seeing a different command is obvious, while using tll() is
> not.

Ok.

>  
>> 9) No benefits, only burden
> 
> It surely is not completely black and white only ;-)

Yes, you're right.

I'm just saying it as I see it. I don't see the benefit you see in a new 
command.

Thanks,

Steve.