[cmake-developers] User vs CMake include mismatch handling [was CMake 2.8.3-rc1 ready for testing!]

[Alexander Neundorf]

On Wednesday 29 September 2010, Alexander Neundorf wrote:
...
> I have some thoughts, but it's not completely clear yet.
> Somehow I think if a file is include()d from CMAKE_MODULE_PATH,
> CMAKE_MODULE_PATH should be considered when it does its own include()s.
> If it's not included via CMAKE_MODULE_PATH (e.g. from cmake's directory),
> CMAKE_MODULE_PATH should be also not considered when it doesn its own
> include()s.
> Something in that direction might make sense...
> Thinking more about this...

Ok, here we go.

The approach comes with a small potential incompatibility problem, which IMO 
is outweighed by the advantage that it should guarantee that CMake itself 
*never* breaks a build, not even if it's the projects fault.

So, the idea is simple:

When a file A calls include/find_package, i.e. cmMakefile::getModulesFile(), 
its own location is considered.

case 1) When A is *not* located in shared/cmake/Modules/, nothing changes. 
First CMAKE_MODULE_PATH is searched, then shared/cmake/Modules/. 
No change or potential incompatibility here.

case 2) When A *is* located in shared/cmake/Modules/, *first* 
shared/cmake/Modules/ is checked, CMAKE_MODULE_PATH afterwards.

In this case there are the following possibilities:
2.1) file A includes a file which exists only in shared/cmake/Modules/: no 
change here

2.2) file A includes a file which does not exist in shared/cmake/Modules/, but 
somewhere in CMAKE_MODULE_PATH (should be a rare case, probably only for 
custom language or platform modules): no change here

And the interesting case, where the behaviour changes:
2.3) file A includes a file which exists both in shared/cmake/Modules/ and in 
CMAKE_MODULE_PATH.

Current behaviour: the file from CMAKE_MODULE_PATH is loaded into file A 
(which is from shared/cmake/Modules/). This can cause breakage as we can see 
with the current problem in KDE. Basically because file A in cmake doesn't 
get the file loaded which it was developed and tested against.

New behaviour: the file from shared/cmake/Modules/ is loaded, i.e. the file 
with which file A was developed and tested, and not a different file provided 
by a user project. This would fix the problem currently in KDE.

Beside that, as a CMake developer, I would strongly prefer this new behaviour, 
since it ensures that no matter what cmake-using projects do with their 
modules, the module files provided by cmake will always work, since they will 
always get the original cmake files with which they were developed and tested 
(somewhat like a RPATH, while the current handling is more like LD_PRELOAD).

Until now I can't think of a way how this could break existing builds.

I think this should go into 2.8.3, if necessary with an extended rc-phase.

Comments ?

Alex

P.S. I'll be offline over the weekend, and next week on business trip until 
Wednesday.