extra-cmake-modules installs into versionned dir
neundorf at kde.org
Sun Feb 19 08:47:22 UTC 2012
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,
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
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
> > > 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
> 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
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
More information about the Kde-buildsystem