[cmake-developers] User vs CMake include mismatch handling

[David Cole]

On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf <neundorf at kde.org>wrote:

> 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
> _______________________________________________
> cmake-developers mailing list
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>


This latest idea does sound better, but I am still not a fan of "invisible /
magic behavior." I much prefer when things are explicitly spelled out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101008/ca6d9cd0/attachment.html>