Include FindKDevPlatform.cmake in kdelibs

[Andreas Pakulat]

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
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
the same prefix is generally not something thats supported by any
library (except boost with their broken naming scheme).

Andreas

-- 
You could live a better life, if you had a better mind and a better body.