On 2012-02-18, Alexander Neundorf <neund...@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
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
