extra-cmake-modules installs into versionned dir

[David Faure]

On Sunday 19 February 2012 09:47:22 Alexander Neundorf wrote:
> 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.

OK, so that was the problem. I had a too old 0.0.2, and when I updated it, it 
became 0.0.3 so kdelibs would not pick it up before manual investigation and 
clearing the corresponding line in the cache.
See? None of this would have happened if install dirs were not versionned.

But yes, it would also not have happened if the version number had been 
increased when this new thing had been added to it, I agree.

> This can be 0.0.2 or 0.0.3, it probably depends which one it sees first
> while searching.

This sounds sub-optimal, compared to "picking up the greatest version number".

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

OK. At *this* point in time I'm not sure it's worth the trouble, I mean not 
until this stuff is officially released and used by other projects. But it's your 
choice.

> 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 

I very much want them to be released together with a common revision number,
anything else is dependency hell, release hell, and version numbering hell. 
But I'll expand on that thought in the right thread later.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5