[cmake-developers] User vs CMake include mismatch handling

[Bill Hoffman]

On 10/11/2010 1:12 PM, Marcus D. Hanwell wrote:
> 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)
>

We really do need to come up with something that will work for existing 
packages.

Also, I would like to have it working very soon, as the RC process is 
just about done for 2.8.3 at this point.  I think this issue has been 
the main delay in the process.

-Bill