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. _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem