Please update extra-cmake-modules, kdelibs (and plasma-frameworks)

Stephen Kelly steveire at gmail.com
Thu Feb 28 23:05:00 UTC 2013


Alexander Neundorf wrote:

> On Thursday 28 February 2013, David Faure wrote:
> ...
>> ... which means it will also fail at link time, not at cmake time.
>> So I don't see the point in this change. I'd must rather write KF5::Solid
>> than ${Solid_LIBRARIES}, where I can never remember if that's LIBRARY or
>> LIBRARIES, and Solid or SOLID, and where such variables come from, etc.
>> They look like an unnecessary additional layer on top...
> 
> Yes, they are an additional layer on top.

An *unnecessary* additional layer :).

One reason I prefer the target names is that it simplifies debugging by 
removing an unnecessary layer. When I see

 target_link_libraries(user ${FOO_LIBRARIES})

and something is wrong, the first thing I have to do is 

 message("FOO_LIBRARIES: ${FOO_LIBRARIES}")

to see what is hidden inside. Please let's not hide things unnecessarily.

If instead it is

 target_link_libraries(user Foo2::foowidgets Foo3::foonetwork )

I can skip the 'remove an unnecessary layer' step and go directly to step 
two.

> For all KF5-libraries, the names are <ExactCaseName>_LIBRARIES.

And the targets are all KF5::<ExactCaseName>. Following a pattern doesn't 
proove usefulness one way or the other.

I agree with David here and Brad on the CMake list that using namespaced 
imported target names is better. I wish you hadn't made the change to use 
variables like that, but now we at least have the topic in discussion.

I suggest that we have consensus (yes, it's not unanimous) that we should 
use target names and imported target names instead. 

We're already using imported target names for Qt targets in some of the 
cases. Please don't replace those with variables. Let's finish the job in 
the direction of using imported targets instead. 

We're also using target names in many cases for in-build targets. Please 
don't wrap any more of those in variables either.

Thanks,

Steve.



More information about the Kde-frameworks-devel mailing list