On 20.10.09 20:36:55, Alexander Neundorf wrote: > 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).
Hmm, thats true indeed. Ok, you convinced me and additionally I only need to change this in one single place :) Comitted to trunk. Andreas -- You never hesitate to tackle the most difficult problems. _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem