Which package will provide the common KDE library version number ?

Alexander Neundorf neundorf at kde.org
Sat Feb 18 16:50:28 UTC 2012


On Saturday 18 February 2012, Kevin Ottens wrote:
> On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
> > On 2012-02-17, Alexander Neundorf <neundorf at kde.org> wrote:
> > > Do we still want a such a common version number ?
> > > If yes, who (which file/package) should define it ?
> > 
> > No. It basically doesn't make sense. Also not in its current usage.
> > 
> > if I e.g. take a kdepimlibs 4.3 and build against kdelibs 4.8, all my
> > pimlibs libraries are versioned like they were pimlibs4.8.
> 
> That behavior is indeed a problem. Still we need a way to ensure that we
> have the same version number accross all frameworks when we release.

In general, when we build one git repository, it doesn't know anything about 
its environment, except:
1. the packages it depends on via find_package()
2. variables defined from the outside via -DFoo=foo
3. ...and environment variables
4. files existing somewhere relative to the source or build tree

For defining the library version numbers, somewhere must be something like:

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.

Option 2) is basically out of the game because I am very sure we should not 
define the version number of a library via a command line parameter. Same for 
option 3.

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

Currently, this "something" seems to contain the shared version numbers, and 
the shared install directories.
It's basically a file which specifies properties of "KDE frameworks" 
libraries.
I.e. a package consisting more or less only of this one (cmake) file holding 
some properties.

Alex


More information about the Kde-frameworks-devel mailing list