>>> On 17-11-2010 at 23:28, in message <aanlktin6z9rxfqprwdux-qge4b_wych_fvy9dyo7d...@mail.gmail.com>, David Cole <david.c...@kitware.com> wrote: > On Wed, Nov 17, 2010 at 4:50 PM, Alexander Neundorf <neund...@kde.org> wrote: >> 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 >> > > We may have discussed it, but it was a while ago, and my brain can't > recall specific details about how we arrived at this point. > > This policy, and all CMake policies should default to OLD. But if a > project says cmake_minimum_required 2.8.4 ... then it can use the NEW > behavior. > > The old behavior is: do not load stuff from CMAKE_MODULE_PATH in a > "special" manner. That should be the default. > > OLD and warn should be the default. Then projects themselves that have > these modules, can say "use cmake 2.8.3 until we have a chance to > update our code... then you can use cmake 2.8.4" > > It should be consistent with all other policies. > > Otherwise, it will be too hard to explain this policy. > > OLD and warn. > NEW if a project explicitly sets it NEW or requires 2.8.4. > > Why should this policy be the first intentional exception to this pattern? > > It shouldn't. > > > David
Hi all, I've been following this discussion with interest for quite a while. I was wondering if both worlds could be united (Alex's and David's) if it were possible to set cmake_minimum_required on the command line? That way Alex can be happy, because he doesn't have to modify CMakeLists.txt files - something he cannot do for previous KDE releaeses; and David will be happy, because old projects will not suddenly break due to some incompatible changes in CMake. BTW: IMHO this new policy should default to NEW for CMake 2.8.4 and later, but I think that's what David suggested as well. Just my 2cts. Regards, Marcel Loose. _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
