[cmake-developers] User vs CMake include mismatch handling

[Brad King]

On 11/18/2010 02:42 PM, Alexander Neundorf wrote:
> 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)

With your proposed NEW policy behavior, how does the project get
find_package(PNG) to use its own FindZLIB?

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

(a) If the copy/modification was taken from an upstream CMake version
not yet released, or a release newer than what is otherwise the minimum
required version, then the project should test the running version of
CMake before adding the module path entry.

(b) If the module is written in the project first and later contributed
to CMake, the project is on its own for dealing with it.

I think this is fully in hands of user projects.  We cannot possibly
account for all possible ways in which the user project will interfere
with CMake's interface.  For example, if a new CMake module adds a
macro whose name matches that that happened to already be used by an
old project release, it will break.

Expecting CMake to deal with the case under discussion is like asking
GCC to deal with this:

 $ echo '#include <stdio.h>' > foo.c
 $ echo '' > stddef.h
 $ gcc -I. -c foo.c
 In file included from /usr/include/stdio.h:75, from foo.c:1:
 /usr/include/libio.h:332: error: expected specifier-qualifier-list before ‘size_t’

When a project decides to do something like your FindZLIB patch example
they have 2 choices:

(1) Contribute the change to CMake upstream and wait for the release
(2) Create their own version with the modification

In case #2 the authors have decided to gain the feature for their current
version with the current CMake at the cost of the current version not
building with a future version of CMake.

Now I think we should actually *undo* the FPHSA fix we did during the
2.8.3 rc series and let older KDEs break with 2.8.4.  If someone wants
to build those older KDEs then you can create a new patch release that
fixes it.  Distro maintainers can include their own patch too.

-Brad