<div class="gmail_quote">On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf <span dir="ltr"><<a href="mailto:neundorf@kde.org">neundorf@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Thursday 07 October 2010, Alexander Neundorf wrote:<br>
> On Wednesday 06 October 2010, David Cole wrote:<br>
> > The really robust solution here is the simple one.<br>
> ><br>
> > It is to implement CMAKE_CURRENT_LIST_DIR and for files that must<br>
> > explicitly reference a file "in the same directory as me", use that<br>
> > explicitly.<br>
> ><br>
> > Otherwise, behavior is exactly the same as it is now.<br>
> ><br>
> > Explicit reference to the file you mean is the only guaranteed way to get<br>
> > the file you mean.<br>
><br>
> This basically means that each include() and find_package() in CMAKE_ROOT<br>
> has to use ${CMAKE_CURRENT_LIST_DIR} to make sure it gets the file from<br>
> CMAKE_ROOT.<br>
> This are 398 places in CMAKE_ROOT which have to be looked at and modified<br>
> accordingly.<br>
> That's what we get automatically and future-proof with the patch.<br>
><br>
> > Anything else is a guess and will be wrong some of the time.<br>
><br>
> No.<br>
><br>
> Speaking as CMake developer: I would expect that when I do<br>
> include(SomeFile) in a file in CMAKE_ROOT in cmake version x.y.z, that I<br>
> can use all features of SomeFile.cmake of this release.<br>
><br>
> Is this a guarantee we want to provide ?<br>
><br>
> I always assumed this. Otherwise I cannot safely use any feature which has<br>
> been added to SomeModule.cmake after its initial release, because some<br>
> project may have an own copy of that file from its initial release.<br>
><br>
> If we want to ensure this, then cmake has to prefer CMAKE_ROOT over<br>
> CMAKE_MODULE_PATH when include()/find_package() is called from inside<br>
> CMAKE_ROOT.<br>
<br>
</div></div>Better idea:<br>
<br>
I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over<br>
CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy will, as<br>
all other policies, default to the old behaviour, but warn.<br>
<br>
For KDE 4.5.0 and 4.5.1 this would mean we get the warning about the weird<br>
include()ing going on (and later on something will break).<br>
<br>
Then there are two choices:<br>
in the next KDE patch release I switch that new policy if present to the NEW<br>
behaviour, so starting with that KDE patch release cmake >= 2.8.3 will work<br>
again.<br>
<br>
The other option is that I set this policy to NEW behaviour in FindKDE4.cmake<br>
(which comes with cmake), i.e. any KDE-using project would automatically get<br>
this new behaviour enabled, and cmake 2.8.3 will be compatible with all<br>
existing KDE releases.<br>
<br>
<br>
I think I prefer the second option, but the first option would be also ok (as<br>
a KDE developer no problem (because it's cmake which breaks), as a cmake<br>
developer quite ok-ish, because at least there is a warning before it<br>
breaks).<br>
<div><div></div><div class="h5"><br>
Alex<br>
_______________________________________________<br>
cmake-developers mailing list<br>
<a href="mailto:cmake-developers@cmake.org">cmake-developers@cmake.org</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers</a><br>
</div></div></blockquote></div><br><div><br></div><div>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.</div><div>
<br></div>