On Mon, May 7, 2012 at 3:12 PM, David Faure <fa...@kde.org> wrote: > On Monday 07 May 2012 13:06:15 Vishesh Handa wrote: > > On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela <nos...@vuorela.dk> wrote: > > > On 2012-05-07, Vishesh Handa <m...@vhanda.in> wrote: > > > > Right. > > > > > > > > We could maintain BC and SC by not touching the kdelibs nepomuk, and > > > > just > > > > making nepomuk-core a dependency of kdelibs. But that would result in > > > > > > both > > > > > > > nepomuk-core and kdelibs installing the same headers. > > > > > > what happens if both libraries are loaded into the same process? > > > > I'm not sure. I'm assuming that it would result in some sort of linker > > errors. > > Not if libnepomukcore is brought in by the application, and libnepomuk is > brought in by a dlopened plugin. In such a case, you get no clear error, > you > get random crashes. > > The solution is usually to namespace the symbols (classes, standalone > functions etc.) so that they don't conflict. > Of course that makes the porting effort a bit higher, but it's the only > way to > have both things side by side during the transition period. >
Oh. 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 :( In all cases, kde-runtime/nepomuk will be removed. Binary and Source compatibility are not affected. > > See knewstuff2 (namespace KNS) vs knewstuff3 (namespace KNS3) for instance > ;) > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 > > -- Vishesh Handa
