[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Thursday 18 November 2010, Brad King wrote:
> 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?

The direct call of find_package(ZLIB) from CMakeLists.txt would get the 
FindZLIB.cmake from CMAKE_MODULE_PATH, since here somebody outside CMAKE_ROOT 
is the includer.

The find_package(ZLIB) inside CMAKE_ROOT/FindPNG.cmake would get  
CMAKE_ROOT/FindZLIB.cmake since FindPNG.cmake is inside CMAKE_ROOT, so 
CMAKE_MODULE_PATH is checked after CMAKE_ROOT.

> > 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.

If it can be ensured that the file stays unchanged, then this would be 
possible. It would add some work, since I would have to maintain several 
cmake module directories.
I would also have to keep track of whether any changes go into any of these 
files, because as soon as a change goes into such a file, it wouldn't be the 
original file anymore and would still have to be used also with the 
originating cmake version.

> (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.

Yes.

> 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’

Yes, that's quite exactly the same effect.

Assuming I would be responsible for stdio.h, and stdio.h is shipped together 
with stddef.h, I would be in the same way happier if I would really get the 
stddef.h included I'm expecting to get. 
I.e. that the "-I." doesn't lead the preprocessor out of "my" directory again 
into "user space".

A difference is maybe that creating your own stddef.h is not considered a good 
idea, while having copies of cmake-modules is common practice.

Considering CMAKE_MODULE_PATH after CMAKE_ROOT when included from CMAKE_ROOT 
protects (the modules shipped with) cmake from being able to be tricked into 
breaking projects.
It's a bit like a protection shield, no matter what users do with 
CMAKE_MODULE_PATH, stdio.h will get the stddef.h it expects.

> 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.

Bill was strictly against that, upgrading cmake must not break any projects.
I would have been somewhat ok with the policy which warns loudly (and I 
will/would make very sure that this policy is set to NEW in KDE as soon as 
possible).
Being able to switch a policy from the command line would make this issue also 
smaller.

Alex