[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Thursday 18 November 2010, Brad King wrote:
> On 11/18/2010 04:20 PM, Alexander Neundorf wrote:
> > 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.
>
> Okay, that works for the case of dependent find-modules as long as the
> project is aware of all the dependencies.  What about fixes to compiler
> info files?  We don't want projects to have to make copies of all the
> Modules/CMake*Information.cmake files and their dependencies.

With the policy set to OLD, nothing changes.
The warning looks currently like this:

--------------
CMake Warning (dev) 
at /opt/cmake-HEAD/share/cmake-2.9/Modules/CheckCXXCompilerFlag.cmake:23 
(INCLUDE):
  File /opt/cmake-HEAD/share/cmake-2.9/Modules/CheckCXXCompilerFlag.cmake
includes /home/alex/src/kde4-svn/KDE_dir/kdelibs/cmake/modules/CheckCXXSourceCompiles.cmake 
(found via CMAKE_MODULE_PATH) which shadows
  /opt/cmake-HEAD/share/cmake-2.9/Modules/CheckCXXSourceCompiles.cmake.  This
  may cause errors later on .

  Policy CMP0017 is not set: Prefer files from CMAKE_ROOT/ when including
...
------------------

Actually I'm happy that cmake can show me these warnings, because each of 
those is a potential breakage in the future (which would be bad for the 
project and also bad for cmake's reputation).
And that's why I think adding this policy is a good thing, even independent 
from the default setting.


The policy set to NEW would indeed break the build for such projects which 
rely on their own compiler info files.
But, as above, this warning would appear, and IMO it is a very valid warning.
Since every cmake upgrade can potentially break their build.

What can be done...

This is in CMakeCInformation.cmake:

IF(CMAKE_USER_MAKE_RULES_OVERRIDE)
   INCLUDE(${CMAKE_USER_MAKE_RULES_OVERRIDE})
ENDIF(CMAKE_USER_MAKE_RULES_OVERRIDE)

IF(CMAKE_USER_MAKE_RULES_OVERRIDE_C)
   INCLUDE(${CMAKE_USER_MAKE_RULES_OVERRIDE_C})
ENDIF(CMAKE_USER_MAKE_RULES_OVERRIDE_C)


So these files could be used.

Or the compiler info files could also optionally look for yet another file to 
include, something 
like "UserSpecific-${CMAKE_C_COMPILER_ID}-${LANGUAGE}.cmake"

Or an additional cmake variable like CMAKE_MODULE_PATH_OVERRIDE could be 
added, which would *always* be searched before CMAKE_ROOT, also when 
including from within CMAKE_ROOT. Or a variable which lists files for which 
CMAKE_MODULE_PATH should be preferred, or some other not too nice special 
casing.

> > Bill was strictly against that, upgrading cmake must not break any
> > projects.
>
> That's an impossible goal unless the projects strictly use our documented
> interface and don't mess with internals at all.  

I wouldn't consider using a slightly modified copy e.g. of FindZLIB.cmake as 
messing with internals.

> The best we can do is establish the contract tests so at least we get early
> warning of some problems.

That's a good thing :-)
I prepared a cmake-builds-kdelibs test (search for "KDE4" in 
Tests/CMakeLists.txt), but didn't get around to set up a nightly build which 
actually enables it (there were these problems with the file system for the 
nightly builds of the Intel compiler, maybe you remember).

Alex