[cmake-developers] User vs CMake include mismatch handling

[Bill Hoffman]

> Remaining are as far as I see:
>
> -set new policy CMP0017 to NEW by default
> Projects with an exotic setup may break, but that's probably better than
> breaking all KDE 4.5.0/1 builds. One could also argue that these projects
> relied on internal implementation details of cmake. As a pro, I think this
> behaviour (include()s from CMAKE_ROOT first check in CMAKE_ROOT) makes sense,
> since we have that dependency but currently it's not enforced.
>
> -hardcode the path to FPHSA.cmake in the find-modules in cmake, probably also
> to CMakeParseArguments.cmake and FindPackageMessage.cmake
> IMO not a solution, just a quick fix for the moment, because we have to
> maintain this forever in the future and basically we need to check *all*
> other include()s in CMAKE_ROOT.
>
> -rename the enhanced FPHSA to FPHSA2
> Worse than above, since this doesn't give any guarantee that the same does not
> happen again in the next cmake release with the renamed function.
>
>
I think at this point we are going to have to go with FPHSA2.

We can work on a longer term strategy for getting around this problem 
after this current release is done.  I want the release to stay on schedule.

In the future, I want to setup a "Contract with CMake" dashboard for KDE 
so that things like this don't happen again, and we are not forced to 
pick a sub-optimal solution.  This (FPHSA change) has been in CMake 
next/master since Aug, and we go to do an RC, and we find out we have a 
problem!

I have started to create "contract" tests.  I have a VTK one that is 
running each night.  It will build a known working version of VTK 
against CMake next.  In a few weeks I will announce this to the lists 
and create a way for projects to setup a contract with CMake test.

Anyway, in the short term, we are going to go with FPHSA2, Alex do you 
have time to do that?

-Bill