extra-cmake-modules installs into versionned dir

[Christophe Giboudeaux]

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
> release).

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
> stuff.
> 

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,
> whatever.

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  
set(SHARE_INSTALL_DIR share/extra-cmake-modules-${ECM_VERSION})

> 
> 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: 
PostgreSQL)

ecm enters in none of these categories.


Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120222/ac2340a1/attachment.sig>