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

[Stephen Kelly]

Alexander Neundorf wrote:
> I also would like to get a concensus on what to  use, that's why I posted
> this issue here.
> I don't think it is KDE style to reach concensus by forcing the majority
> vote on the maintainer and just dismiss his arguments.

Yes, sorry. I was too quick with that.

> 
> * Using imported target names directly extends the scope of cmake source
> compatibility. 

I don't think I understand. In your opinion, should using target names 
directly not carry an expectation of source compatibility? In your opinion, 
should the possibility of using target names be 'supported' or documented?


> * First sentences from the documentation of find_package():
> "Finds and loads settings from an external project. ... When the package
> is found package-specific information is provided through variables
> documented by the package itself."

That's just a bug in the cmake docs.

> There is not even an
> official recommendation to use a namespace at all when exporting.
> So from find_package(SomeLib) you cannot even guess what the name of the
> imported target will be (looking beyond KF5 and Qt5), it may be
> "Some::Lib", or "somelib", or "some" or anything else.

That may be a broader issue, but I don't think this is a problem for KDE. 
For the KDE frameworks, we will use the KF5:: prefix.

> * If we stay with the convention as defined by the find_package()
> documentation, whenever a developer sees e.g. a
> target_link_libraries(... ${Stream_LIBRARIES})
> , he can assume that there is somewhere a find_package(Stream) call. This
> is good. If there is instead
> target_link_libraries(... stream)
> there is no indication whether this is an in-project target or an imported
> target

Again, while this might be a broader issue for cmake users, it's not a KDE 
problem. For the KDE frameworks, we will use the KF5:: prefix.

> * it shall be usable as an example for projects outside KDE which look
> around for how cmake should be used (that's why it doesn't matter that in
> KF5, all exported targets have the same prefix and the library has the
> same name as the package. This is simply irrelevant for other projects).

I don't really think this is a KDE problem. There are many projects out 
there using cmake. Someone trying to figure out how to use cmake wouldn't 
need to look to KDE to find out, as they might have had to in 2006. There 
are smaller and simpler projects to learn from. And if they do look to KDE, 
and see imported targets with namespaces, why would they not mimic that, if 
mimicry is the aim?

> 
> (*1) Ok, variables are not the only existing option, but the only viable
> option.

Sounds fair enough.

Thanks,

Steve.