[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Thursday 18 November 2010, Brad King wrote:
> On 11/18/2010 04:29 AM, Marcel Loose wrote:
...
> This entire issue is about projects using CMAKE_MODULE_PATH to override
> standard CMake modules (accidentally or intentionally).  This "policy"
> changes the *granularity* at which that has to happen.  Previously
> a project could just copy out *one* module and modify it to fix
> something.  Now it would need to copy out all modules that depend on
> that module too.
>
> This is typically done to fix a bug or gain a feature without waiting
> for a new CMake release.  Ideally the project should have a separate
> entry in CMAKE_MODULE_PATH for each version of CMake, and then only
> add those corresponding to versions of CMake newer than or equal to
> that running.  IOW the outside project takes responsibility for the
> management of module "override" versions.
>
> Part of the design of policies is that the NEW behavior is clearly
> superior to the OLD behavior in design and function.  IMO, the NEW
> behavior of the proposed policy does not have this clear distinction.
> It makes the typical use case harder to do.
>
> This discussion should instead refocus on a way to make it easier for
> projects to deal with the above copy-and-fix-for-this-version use case.
> The approach should make it easy for CMake to know whether or not to
> honor a certain project module directory based on its version.

Ok.
Assume a project includes only a copy of FindZLIB.cmake from cmake 2.8.3 and 
applies the attached patch (or some similar simple patch).
Assume it does:

set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/CMakeModules/)
find_package(ZLIB)
find_package(PNG)


What should it do to make sure a future cmake release with fully backward 
compatible changes doesn't break its build ?

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindZLIB.cmake.patch
Type: text/x-diff
Size: 370 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101118/2793b02a/attachment-0002.patch>