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

[Alexander Neundorf]

On Tuesday 05 March 2013, Stephen Kelly wrote:
> Alexander Neundorf wrote:
...
> > * 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?

If people start to use names of imported targets from project Foo directly, 
cmake source compatibility of Foo does not only depend on the variables set in 
the Find/Config-files, but now also on the naming of the targets within Foo.

So currently the Find/Config-files-layer isolates users of Foo from changing 
names of targets, output file names or include directory names within Foo, by 
using the imported target names directly this isolation goes away.

 
> > * 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.

Well...
I don't think we should start discussing whether this is a bug or not.
I mean, since there is no standard for the CMake language, one could argue 
that the documentation is the definition of it, and so by construction bug-
free, and only cmake can have bugs by not doing what the docs say ;-)

 
> > 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 start doing it here, our developers will assume this is the way to do it 
and take this everywhere, at their workplaces, to other projects, etc.
So this is an issue for me.
We should not do things which we can't recommend in general.

We do that e.g. in KDE4 with installing Find-modules. I started this in 
kdelibs, and I regret it. People saw it there, and thought it's ok to do it, 
and then several other KDE modules started to install Find-modules. Probably 
non-KDE projects then did it too.
Questions and issues arose, because I did something which in hindsight was not 
good in general.

That naming issue is a big one for me, I'll reply to that longer on cmake-
devel.

> > * 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.


I agree that when using a namespace like "Foo::", things are relatively 
obvious.
But the same as above applies.

> > * 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?

As I said, the only really forcing argument is the one about the current 
situation in kdelibs and that it can be built in two ways.
This last one is more on the personal side :-)

Alex