[Bug 153463] [PATCH] Make Kompare build/work in KDE 4.0 SVN (3.96.2)

Kevin Kofler kevin.kofler at chello.at
Tue Dec 11 16:58:33 CET 2007


> I don't think adding a SOVERSION makes much sense as there's no BC
> guarantee for those two libraries - they are simply convenience libs to
> not have to build the sources of each lib three times when building
> kompare. So if we add a SOVERSION we need to make sure to increase it
> every time we break BC in the libs.

Well, technically an arbitrary constant SOVERSION and no version at all have 
the exact same effect there (what's the technical difference between a foo.so 
which doesn't maintain any BC and a foo.so.31337 which doesn't maintain any 
BC? In both cases, packages will fail at runtime without the RPM soname 
dependency mechanism detecting any problem), it's just the expectations which 
are different.

If you want to use libdiff2 in KDevelop, won't we need a properly versioned 
and BC-maintaining library anyway? That said I don't think we're ready for 
that right now.

> So if you don't like them being shared libs its easy enough to change
> the CMakeLists.txt to directly compile the .cpp's into the part,
> navtreepart and the application. Which is what I prefer over adding a
> SOVERSION.

I think the shared library is probably the cleanest solution as not only we 
don't have to build things twice, but we also don't load them twice (into the 
SAME executable, that's both a waste of memory and a PITA when debugging). 
I'm just not too thrilled about them being unversioned, but that's just a 
minor annoyance when packaging. So if a versioned .so is not a usable option, 
I'd say we just keep the unversioned .so.

        Kevin Kofler


More information about the Kompare-devel mailing list