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
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
