On Wednesday 17 November 2010, David Cole wrote: > 2010/11/17 Alexander Neundorf <neund...@kde.org>: > > 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 > > It doesn't make sense to introduce a policy that defaults to NEW. The > reason for adding a policy is to *avoid breaking* existing projects. > > The default / OLD behavior should not break anything. It is when > switched to NEW that stuff might break. > > How is it that projects will break with the OLD behavior of this > policy? If OLD breaks stuff, then it's not really OLD...
Hmm, we discussed this here at length already... With no change in behaviour (i.e. old behaviour), if some cmake module inside CMAKE_ROOT does include(SomeFile), and then uses some features of SomeFile.cmake introduced in the same cmake version in a backward compatible way, this breaks if there is another user-supplied SomeFile.cmake in CMAKE_MODULE_PATH (maybe just a copy from the previous cmake release), because that "old" SomeFile.cmake doesn't have yet the features present in the current cmake version which the SomeFile.cmake-using module expects to be present (because it's not forward-compatible). With this policy a module in CMAKE_ROOT can rely on the fact that it also gets the module it expects, i.e. the one also from CMAKE_ROOT and not another, potentially old and incompatible one, from CMAKE_MODULE_PATH. That's why this policy has to be set to NEW to avoid breakage. The result from the discussion here was to use the full path as a quick fix for 2.8.3, and as soon as this is out, use the new policy and see whether/how much breakage there is. Alex _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
