Include FindKDevPlatform.cmake in kdelibs

[Alexander Neundorf]

On Tuesday 20 October 2009, Andreas Pakulat wrote:
> On 20.10.09 19:20:08, Alexander Neundorf wrote:
> > On Monday 19 October 2009, Andreas Pakulat wrote:
> > > On 19.10.09 23:06:06, Alexander Neundorf wrote:
> > > > On Monday 19 October 2009, Andreas Pakulat wrote:
> > > > > On 19.10.09 18:47:45, Alexander Neundorf wrote:
> > > > > > On Sunday 18 October 2009, Andreas Pakulat wrote:
> > > > > > > On 17.10.09 16:20:11, Andreas Pakulat wrote:
> > > > > > > - copy the find-module to kdelibs/trunk and kdevelop/trunk so
> > > > > > > we have a duplicate until kdevelop depends on KDE 4.4. I don't
> > > > > > > like the duplicate-part obviously..
> > > > > > > - Move the file to kdelibs/trunk and make kdevelop depend on
> > > > > > > KDE 4.4. Thats going to frustrate quite some users.
> > > > > > > - Copy the file to kdelibs/trunk and leave it in kdevplatform
> > > > > > > until we require KDE 4.4. This is going to create a file
> > > > > > > conflict for distributions, so not very nice either.
> > > > > > >
> > > > > > > Did I miss one that works better than option 2? Else I'll do
> > > > > > > that one.
> > > > > >
> > > > > > Yes, I think I would prefer that one too.
> > > > >
> > > > > Ok, thats going to be the one I'm taking.
> > > > >
> > > > > > Could you please also post the cmake files installed by
> > > > > > kdevplatform (which are found by this one here) ?
> > > > >
> > > > > Sure, attached are the .cmake ones and the final generated ones as
> > > > > well (from my system).
> > > >
> > > > Looks good I'd say.
> > >
> > > Thanks :)
> > >
> > > > I would consider using some prefix for the imported library target
> > > > names, this makes it obvious if something there went wrong (e.g. if
> > > > you get an email complaining that -lKDevPlatform__sublime can't be
> > > > found).
> > >
> > > Hmm, except sublime they're all prefixed with kdevplatform already. And
> > > sublime is "originally" special as its not tied to kdevplatform and was
> > > meant to be a standalone library...
> >
> > No, I mean the NAMESPACE feature of the INSTALL(EXPORTS ... ) command.
> > This way the names of the exported/imported targets can get a prefix, so
> > they are easier to recognize. This doesn't affect the names of the
> > generated libraries, nor the names of the variables. E.g.
> > "KDevPlatformImported__" might also be a good candidate.
>
> I can't really see the benefit when having
> KDevPlatform(Imported)__kdevplatforminterface as target name. I mean
> the names we currently have are already pretty unique and I doubt

Yes, it's no big thing.
But it makes it kind of obvious that e.g. 
KDevPlatformImported__kdevplatforminterface is the name of an imported 
target, and not the name of a library and not the name of a "real" target.
It was kind of nice when somebody was complaining that something didn't link 
for him, and the link command was something 
like "g++ .... -lKDE4__kdecore ..."
This made it very clear that the problem was that there was an issue with the 
imported targets and not something else (e.g. in "-lkdecore" the "kdecore" 
could have been both - the name of an imported target or the name of the 
library).

> another cmake project would use the same (except as I said for the
> sublime library - but I'm thinking about making it a kdevplatform lib
> too).
>
> > > > Did you figure the version stuff out ?
> > > > (if so, feel free to add it to techbase :-) )
> > > > I still didn't get around to do it.
> > >
> > > That was about the benefits of naming the lib/cmake/foo directory with
> > > the version number right? Or was there something else - in which case I
> > > completely forgot about it...
> >
> > Yes.
>
> No I still don't see a benefit in using the versioned-variant. If I
> understood correctly cmake doesn't use that information for finding the
> right version, it only uses the FooConfigVersion.cmake file and
> installing the development-parts of two versions of the same library in

Have to look up the details again...

Alex