On Thursday 14 October 2010, David Cole wrote: > On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf <neund...@kde.org>wrote: > > On Wednesday 13 October 2010, Alexander Neundorf wrote: > > > On Wednesday 13 October 2010, Bill Hoffman wrote: > > > > So, I think we have to use the new name approach. Do we want to call > > > > it > > > > > > 2? Or should we call it something else? > > > > > > > > Alex, do you have time to do this? > > > > > > I think it's not a good solution, and the one with CURRENT_LIST_DIR is > > > definitely better and already implemented. > > > And I am still convinced that I am right here, see my other mails. > > > > So I would suggest to merge the CURRENT_LIST_DIR branch for 2.8.3, and as > > soon > > as 2.8.3 is released, remove the full paths again and enable the new > > CMP0017 > > instead (prefer CMAKE_ROOT when include()d from CMAKE_ROOT) and then see > > what > > happens during the whole 2.8.4 cycle. > > > > I think this (CMP0017) is necessary, because otherwise we can only hope > > nothing breaks with future releases (independent from FPHSA). > > > > Alex > > _______________________________________________ > > cmake-developers mailing list > > cmake-developers@cmake.org > > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > > I'm ok with this since Alex feels so strongly about it, and the code change > is restricted to using CMAKE_CURRENT_LIST_DIR only when including > FPHSA.cmake... (i.e. -- it should not affect including *other* files from > inside of modules that are presently overridden... which was my concern -- > that we'd break some *other* scenario -- since that's not true, I retract > my objection.) > > To review the change yourself: > git fetch stage > gitk remotes/stage/AddCMAKE_CURRENT_LIST_DIR > > Look at the top 3 commits. Looks pretty safe. I'd say we should merge it to > 'next' and then after a night on the dashboards, merge it to 'master' and > do an rc3 release based on that.
There is now a branch PreferCMakeModulesByCMakeModulesWithPolicy-NoTrailingWhitespaceCommit on stage. This contains right now only one commit, and that's the commit which adds a policy which decides whether files in CMAKE_ROOT are preferred over CMAKE_MODULE_PATH if include()d from withing CMAKE_ROOT. Currently (in this branch) this new policy is set to WARN, i.e. still the old behaviour by default. As discussed, I think for this policy the default has to be new, because otherwise it doesn't have the desired effect, (with WARN the projects will break, but with warnings). So, are you ok if I set this policy to NEW by default ? I would also remove the full path for the include(FindPackageHandleStandardArgs) in this branch again. If there are no objections, I'll do this in the next days and then merge into next. Alex _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
