On Saturday 18 February 2012, Kevin Ottens wrote:
> On Saturday 18 February 2012 17:50:28 Alexander Neundorf wrote:
> > 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 <neund...@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.
>
> Which leaves us the option 4 which is what I proposed in my previous email
> for release tarballs. You point out indeed a proper issue for the hash in
> version number for a library in the case of developer builds... We'd need
> to derive a proper version number in such case, not sure how.
>
> > 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.
>
> Which would then recreate the problem Sune pointed out. Depending on which
> package got picked up you change the version number of the library even
> though the code base is the same.
Well, suppose a frameworks library, e.g. solid, has:
find_package(KF5Specs REQUIRED)
set_target_properties(.... VERSION ${KF5_LIBRARY_VERSION} )
IMO it would be fine.
I mean, if I build this library then against KF5Specs version 7.12, then my
library is per definition part of KF5 7.12.
> So the other possibility would be to have the version number in the main
> CMakeLists.txt of each framework
This is the clean and obvious way to do it.
Each library defines its own version number.
But...
> which raises potential consistency issues...
Exactly.
> Solution would then be that the scripts used to generate the
> release tarballs verify the version is properly set everywhere.
...or scripts which regularly update the version numbers in git.
Alex
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
