[cmake-developers] User vs CMake include mismatch handling

[David Cole]

On Wed, Nov 17, 2010 at 4:50 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Wednesday 17 November 2010, David Cole wrote:
>> 2010/11/17 Alexander Neundorf <neundorf at kde.org>:
>> > On Thursday 14 October 2010, David Cole wrote:
>> >> On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf
> <neundorf at 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 at 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