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 _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
