extra-cmake-modules installs into versionned dir

[Alexander Neundorf]

On Saturday 18 February 2012, David Faure wrote:
> On Saturday 18 February 2012 18:45:54 Alexander Neundorf wrote:
> > On Saturday 18 February 2012, David Faure wrote:
> > > Same problem as what we fixed in kdepimlibs long ago...
> > > 
> > > extra-cmake-modules installed itself into
> > > 
> > >   share/extra-cmake-modules-0.0.2
> > > 
> > > and after updating it now installs itself into
> > > 
> > >   share/extra-cmake-modules-0.0.3
> > > 
> > > which means that 1) the cmakecache.txt in kdelibs pointing to 0.0.2
> > > creates
> > > much trouble, one has to clean up the cache to be able to compile
> > > kdelibs again,
> > 
> > Why, what has been broken ?
> > I tested it here, and it worked just fine for me.
> 
> I had errors about Qt5Transitional not being found (it's only in 0.0.3,
> right?), 

No.
It was added it a few days ago (in 0.0.2).
I guess whenever something like this happens, the version number has to be 
increased, and everywhere where the new stuff is used, the increased version 
has to be required.

> then errors about KDE4Internal not being found (I fixed that one).
> But before all that I had
> 
> install TARGETS given unknown argument "EXPORT".
> 
> which is what led me to update cmake+ECM.
> 
> > > and 2) as long as kdelibs's toplevel CMakeLists.txt said "0.0.2", it
> > > would pick up the 0.0.2 subdir, even after cleaning up the cache!
> > 
> > It picks any matching version, i.e. 0.0.2 or 0.0.3.
> 
> But if you have both installed, it will pick 0.0.2, right?

If CMakeLists.txt says it needs version 0.0.2, cmake will pick *any* version 
which matches.
If it already has a version which is good enough, it will continue to use it.
If you clean this entry from the cache, it will search again, and use the 
first version it finds which matches.
This can be 0.0.2 or 0.0.3, it probably depends which one it sees first while 
searching.
 
> > > 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.
> > 
> > If you have 0.0.2, and your CMakeLists.txt says:
> > find_package(ecm 0.0.2)
> > and everything works, everything is fine. 0.0.3 next to it shouldn't
> > create any problems.
> > 0.0.3 has new stuff, if you want to use it, you have to depend on it:
> > find_package(ecm 0.0.3)
> > then you get the newer version (but I wouldn't do this right now, 0.0.2
> > is fine).
> 
> Clearly it doesn't -- I wasn't the only one who couldn't configure kdelibs
> today.
> If you find out what went wrong we can revert the min number in kdelibs
> toplevel CMakeLists.txt... but I'm not sure that supporting multiple
> versions of ECM is worth the trouble?

I want e-c-m to be very independent from KDE SC, like kdesupport. It should 
not bee seen as a project with KDE dependencies, just happened to be hosted on 
KDE servers and started by KDE developers.
When we work on e-c-m, we must be very careful, because we may break builds 
from people (as seen here). I think we (people committing to e-c-m) must be 
aware of this.

I want to be able to install multiple versions at the same time, right from 
the start.

Won't we run into similar issues when kdelibs will finally be split into 
multiple repositories with dependencies between each other ?
They won't even have a common revision number and atomic commits like they had 
in svn anymore (see my other mail about what makes a library a KDE frameworks 
library).

Alex