[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Tuesday 12 October 2010, Bill Hoffman wrote:
> > 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?

FPHSA2 would have been my last choice.

In staging there is already the branch AddCMAKE_CURRENT_LIST_DIR:
http://cmake.org/gitweb?p=stage/cmake.git;a=log;h=refs/heads/AddCMAKE_CURRENT_LIST_DIR

where I implemented the option with the hardcoded paths:

-INCLUDE(FindPackageHandleStandardArgs)
+INCLUDE("${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake")

This doesn't introduce a macro with a new name (i.e. without an appended "2") 
which we then have to maintain forever, and makes also sure that the correct 
FPHSA.cmake is loaded by cmake 2.8.3 (which FPHSA2 does only for cmake 2.8.3, 
but not for coming cmake > 2.8.3, and I think it is quite likely that 
FPHSA()/FPHSA2() will get more options in coming releases)

Even while I think this is not a good solution, it is a safe short-term fix, 
and we can figure out for 2.8.4 how we should handle CMAKE_MODULE_PATH in the 
long term.

Alex