Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in the future, we could just change the macro value.
I don't know, thinking that Nepomuk2 namespace is looking rather ugly :) The dirtiest solution library-wise would be to have everything in NepomukCore::Nepomuk::Something so that the only change in the current code of nepomuk users would be a using namespace NepomukCore; Sorry for being a bit vague, I'm writing from my phone. Cheerio, IvanOn 7.5.12. 14.49 Vishesh Handa wrote: On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg <tr...@kde.org> wrote: On 05/07/2012 02:35 PM, Vishesh Handa wrote: > > > On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg <tr...@kde.org > <mailto:tr...@kde.org>> wrote: > > > On 05/07/2012 12:09 PM, Vishesh Handa wrote: > > > So, we're down to 3 options - > > > > *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not > touched. > > *Problem:* Overlapping headers and possible mysterious crashes if both > > libraries are loaded. > > > > *2.* nepomuk-core installs headers under nepomuk2. It's released > > independently. > > *Problem:* Mysterious crashes if both libraries are loaded. > > > > *3.* nepomuk-core installs headers under nepomuk2 and the namespace is > > changed to nepomuk2. > > *Problem:* A lot more work :( > > Well, I suppose we could make this work with some sed magic. :P > I would vote for option 3 which could then be reverted (or not) for > kde5. > > > I would prefer option 2. > > The mysterious crashes would only happen if an application's plugin > links to the incorrect libraries. > > Is that a possibility for us? I already experienced that. Took me a while to find the reason. Alright. I would like the Nepomuk2 namespace and include directories be removed for the frameworks, but I guess it is not a big deal if that doesn't happen. ---- Okay, everyone. This is the point where you chime in and say - "We're okay with this" or you raise your objections. We would like to get this mess sorted in time for the 4.9 release. -- Vishesh Handa
