Which package will provide the common KDE library version number ?

Sune Vuorela nospam at vuorela.dk
Wed Jun 20 20:31:03 UTC 2012


On 2012-02-18, Alexander Neundorf <neundorf at kde.org> wrote:
> set_target_properties(Foo PROPERTIES VERSION ${VERSION_NUMBER}
>                                      SOVERSION ${SOVERSION_NUMBER} )
>
> These two version numbers should always have sensible values.
> I didn't test, but I'm not sure a libfoo.so.3dea0a0c6be9df8db4d01d6d5 actually 
> works.

I'm not sure if there is a length limit somewhere, but you can put more
or less everything there. quite many libraries from e.g. curret
kde-workspace has a libfoo.so.4abi4 version.

> Seriously, if the libraries share something, which makes them "KDE frameworks 
> libraries", then this something should exist.

I still don't think there is a need.

> Currently, this "something" seems to contain the shared version numbers, 

This can just as easy be done by a script. the very simple:
#! /bin/sh
RELEASE_MAJOR=5
RELEASE_MINOR=3
RELEASE_PATCH=1
for i in frameworks/*/ 
do
  echo $RELEASE_MAJOR > $i/SOVERSION
  echo $RELEASE_MAJOR.$RELEASE_MINOR.$RELEASE_PATCH > $i/VERSION
done

and have a bit of cmake to parse these bits.

> and 
> the shared install directories.

I'm also not sure we need shared installdirectories. Sure, most people
will put everything together, and we could even honour a
KDE_FRAMEWORKS_PREFIX env var for convenience.

Sure, this means clueless people can shoot themselves in their feet by
using a different prefix for each, building without RPATH and not
setting LD_LIBRARY_PATH nor any paths to cmake.

> I.e. a package consisting more or less only of this one (cmake) file holding 
> some properties.

I basically find this a useless extra dependency imposed because we can,
not because we have any need for it.

/Sune



More information about the Kde-frameworks-devel mailing list