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.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
