[cmake-developers] User vs CMake include mismatch handling

[Marcus D. Hanwell]

On Sunday 10 October 2010 14:56:29 Alexander Neundorf wrote:
> On Friday 08 October 2010, David Cole wrote:
> > On Fri, Oct 8, 2010 at 10:59 AM, Alexander Neundorf 
<neundorf at kde.org>wrote:
> ...
> 
> > > Better idea:
> > > 
> > > I'll add a policy which switches this behaviour (prefer CMAKE_ROOT over
> > > CMAKE_MODULE_PATH when used from within CMAKE_ROOT), and this policy
> > > will, as all other policies, default to the old behaviour, but warn.
> 
> ...
> 
> > This latest idea does sound better, but I am still not a fan of
> > "invisible / magic behavior." I much prefer when things are explicitly
> > spelled out.
> 
> There is now a branch "PreferCMakeModulesByCMakeModulesWithPolicy" on
> staging. It includes this patch, a new policy CMP0017, and a basic test
> for it.
> 
> I also verified that this fixes the KDE 4.5 problem.
> With KDE 4.5.0/4.5.1 there are now a lot of these new CMP0017 warnings, and
> in the end stuff has not been found which should have been found.
> 
> Should I handle setting CMP0017 to NEW in kdelibs (-> cmake 2.8.3 will not
> be able to build KDE 4.5.0/1, but complain loud) or in
> CMake/Modules/FindKDE4.cmake (then cmake 2.8.3 will be able to build KDE
> 4.5.0/1) ?
> 
So is there no chance of fixing this in a backward compatible way? One of 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).

I tested your topic branch with this project, and it still fails with the 
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)

Marcus