KDE/kdelibs/cmake/modules

[Alexander Neundorf]

On Friday 04 January 2008, Lubos Lunak wrote:
> On Friday 04 of January 2008, Alexander Neundorf wrote:
> > On Friday 04 January 2008, Lubos Lunak wrote:
> > > On Friday 04 of January 2008, Alexander Neundorf wrote:
> > > > Yes, it is very unlikely, but very unlikely != impossible.
> > > > The thing is, the names were in sync with the names of the variables
> > > > in the FindX11.cmake of cmake cvs since several months.
> > > > So since several months some cmake cvs users may already use that
> > > > variable. Ok, it is the cvs version only, but still it is there for
> > > > quite some time already and changing this can break the build of
> > > > somebody (you never know what somebody does with the variables). So
> > > > this change means either we can never use the module from cmake or I
> > > > need to add some transition logic on the cmake side.
> > > > So is it really necessary to change the name ?
> > >
> > >  I guess that depends on which of changing a rarely used name from
> > > cmake cvs and having a confusing rarely used name you consider to be
> > > worse.
> >
> > I mean, it was that way since February 23rd, 2006, and you changed it now
> > after almost two years only hours before tagging 4.0.0 without sending a
> > patch first.
> >
> > Although unlikely, this was a source incompatible change.
>
>  Change it back if it's so. 

What's the current state of 4.0.0 tagging/packaging ?

> Sorry, I didn't realize we have a copy of large
> portion of CMake in our SVN. 

We have a bunch of own cmake modules (which don't exist in CMake) and we have 
some modified copies of CMake modules there.
My goal has been to sync from time to time with cmake, so that later on we can 
remove some of our own modules and rely on the ones which come with cmake.
FindX11.cmake is one of them.

> Does that mean we shouldn't touch anything under cmake/ ?

No, I'm actually happy that there are so many people working on the stuff 
there :-)
Developers just need to be aware that changing things in cmake can also mean 
source incompatible changes.

This also means we have to make sure they stay compatible for all KDE 4.x.y 
just the same way as we do for the actual sources.

Alex