[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Monday 11 October 2010, Marcus D. Hanwell wrote:
> On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
...
> So is there no chance of fixing this in a backward compatible way? One of

Prefering module in CMAKE_ROOT when include() or find_package() is called from 
CMAKE_ROOT (which does have the potential to break existing builds, but those 
projects must have a weird setup I think).

> the projects I work on has been bitten by this too, and so I guess the old,
> released versions are doomed to fail with CMake 2.8.3 with the current
> solution. This seems like quite a regression, and something the policies
> were supposed to avoid (old projects failing with new CMake versions).

Hmm, this would mean that the module which uses FPHSA() would have to check 
how the new policy is set and depending on this call FPHSA() with the old or 
the new enhanced syntax. That's also ugly I think, and worse than using 
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)

This would fix the current problem, but IMO this is not a real solution, since 
it can break also for other modules, and then this hardcoded path must be 
used also in the future in all find-modules.
I think prefering the modules from CMAKE_ROOT when included from CMAKE_ROOT is 
the right thing to do. This expresses the dependency we have (from cmake 
modules to the other current cmake modules in CMAKE_ROOT).

> I tested your topic branch with this project, and it still fails with the

You should get the policy warning about CMP0017.
Is that the case ?

> following error,
>
> CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:53
> (MESSAGE): REQUIRED_VARS
> Call Stack (most recent call first):
>   /usr/local/share/cmake-2.8/Modules/FindZLIB.cmake:70
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   CMakeLists.txt:234 (find_package)

I see the following options:
* set policy 0017 to NEW behaviour by default (is that possible ?)
* set policy 0017 to NEW behaviour somewhere locally. What project is 
failing ?
* hardcode ${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake 
instead of just using include(FindPackageHandleStandardArgs), problems see 
above
* revert the enhanced syntax :-( or put it into a file 
FindPackageHandleStandardArgs2.cmake (but the same can happen later on 
again) :-/


Personally, I would try a rc3 with CMP0017 set to NEW and see how it goes.
It works for kdelibs and for our project at work (which doesn't have a lot of 
fancy cmake stuff).

Alex