extra-cmake-modules installs into versionned dir
cgiboudeaux at gmx.com
Wed Feb 22 18:20:48 UTC 2012
On Wednesday 22 February 2012 18:33:02 Alexander Neundorf wrote:
> On Tuesday 21 February 2012, Christophe Giboudeaux wrote:
> > On Monday 20 February 2012 19:38:37 Sune Vuorela wrote:
> > > On Saturday 18 February 2012 18:45:54 Alexander Neundorf wrote:
> > > > On Saturday 18 February 2012, David Faure wrote:
> > > > > Can we PLEASE get rid of the version number in the install
> > > > > directory?
> > > > > It's way more trouble than any benefit it might bring.
> > > > >
> > > > > If one day we want co-installable incompatible releases,
> > > >
> > > > I want to have co-installable releases right from the beginning.
> > >
> > > I don't. It makes no sense what so ever to have it, and it is only
> > > giving
> > > headaches to the users of ecm.
> > Agreed. and I fully support removing this versioned prefix. I consider
> > this
> > a showstopper (ie: I would invite people to stay away from ecm to avoid
> > headaches).
> > The past experiences with kdepimlibs and kdebase-workspace have been
> > complete failures and both were fixed. (I fixed kdepimlibs in 2009 and
> > Thiago fixed kdebase-workspace last year).
> > The reason is quite simple: we don't bump the version after each feature
> > or
> In e-c-m the version *must* be increased for every added feature (in a
Erm.. You noticed that's it's currently 0.0.3 and that it already has 2313
commits, right ?
Anyway, the issue is not the version but the installation prefix.
> > bug fix and if someone has a build error, the answer is "update
> > thisModule"
> > rather than "update thisModule to X.Y.Z version."
> > Additionally, this requires bumping the minimum version in the depending
> > module. You're then facing two issues:
> > - You're not supposed to try each version to find the right one,
> When using a feature, you have to know in which version it is.
> We'll need to provide a way to make this easy to find out.
... and if you don't know, you simply use the latest.
> > - You can't use find_package(FOO) without the version since cmake will not
> > check whether his cache should be refreshed.
> Yes, and in general you shouldn't, since every new version will have new
Well, and ? You won't reinvent the wheel each time you bump the version. Once
again, using the latest will be the wisest choice.
> > Concurrent installation are still possible using different install prefix
> > and just playing with CMAKE_PREFIX_PATH.
> I may think about leaving the patch-level version number out, but beside
> that it will stay versioned.
> So that the patch level version is kept for bugfixes, which should be
> compatible, and the minor version can contain new features.
> Whatever feature you use, you have to make sure using the minimum required
> version that you get a proper version of e-c-m.
Once again, this is unrelated to the installation path.
> Everything you describe is no reason against versioned installs.
and what you describe is no good reason to keep it.
> Remember, e-c-m is no typical KDE package, not at all.
> It is intended to be used by any projects, KDE, Qt, gtk, EFL, XCode,
and they'll be facing the same issue our developers had with versioned
kdepimlibs and kdebase-workspace (and will most certainly have with ecm if the
current behaviour is kept).
> You are correct that to use it properly, you need to use the minimum
> required version.
> There is absolutely no way around this, and this is completely independent
> from whether the install dir is versioned or not.
There I agree, we need a minimum version, but that's not a reason for keeping
> If you use some feature from a released e-c-m version, you have to check in
> which version this feature has been introduced.
and again, the installation prefix is of no use for this.
What do you think packagers will do ? provide different versions or use the
last one ?
We (packagers) have absolutely no interest in having several versions on the
same application since that means:
- more maintenance,
- more space,
- more potential packaging issues.
Having several parallel installations make sense only in a few cases:
- Libraries when their soname is changed
- Very specific applications that are not runtime compatible (example:
ecm enters in none of these categories.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Kde-buildsystem