[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