[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Thursday 07 October 2010, Alexander Neundorf wrote:
> On Wednesday 06 October 2010, David Cole wrote:
> > The really robust solution here is the simple one.
> >
> > It is to implement CMAKE_CURRENT_LIST_DIR and for files that must
> > explicitly reference a file "in the same directory as me", use that
> > explicitly.
> >
> > Otherwise, behavior is exactly the same as it is now.
> >
> > Explicit reference to the file you mean is the only guaranteed way to get
> > the file you mean.
>
> This basically means that each include() and find_package() in CMAKE_ROOT
> has to use ${CMAKE_CURRENT_LIST_DIR} to make sure it gets the file from
> CMAKE_ROOT.
> This are 398 places in CMAKE_ROOT which have to be looked at and modified
> accordingly.
> That's what we get automatically and future-proof with the patch.
>
> > Anything else is a guess and will be wrong some of the time.
>
> No.
>
> Speaking as CMake developer: I would expect that when I do
> include(SomeFile) in a file in CMAKE_ROOT in cmake version x.y.z, that I
> can use all features of SomeFile.cmake of this release.
>
> Is this a guarantee we want to provide ?
>
> I always assumed this. Otherwise I cannot safely use any feature which has
> been added to SomeModule.cmake after its initial release, because some
> project may have an own copy of that file from its initial release.
>
> If we want to ensure this, then cmake has to prefer CMAKE_ROOT over
> CMAKE_MODULE_PATH when include()/find_package() is called from inside
> CMAKE_ROOT.

Better idea:

I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over 
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy will, as 
all other policies, default to the old behaviour, but warn.

For KDE 4.5.0 and 4.5.1 this would mean we get the warning about the weird 
include()ing going on (and later on something will break).

Then there are two choices:
in the next KDE patch release I switch that new policy if present to the NEW 
behaviour, so starting with that KDE patch release cmake >= 2.8.3 will work 
again.

The other option is that I set this policy to NEW behaviour in FindKDE4.cmake 
(which comes with cmake), i.e. any KDE-using project would automatically get 
this new behaviour enabled, and cmake 2.8.3 will be compatible with all 
existing KDE releases.


I think I prefer the second option, but the first option would be also ok (as 
a KDE developer no problem (because it's cmake which breaks), as a cmake 
developer quite ok-ish, because at least there is a warning before it 
breaks).

Alex