[cmake-developers] User vs CMake include mismatch handling

[Alexander Neundorf]

On Wednesday 13 October 2010, Alexander Neundorf wrote:
> On Tuesday 12 October 2010, Brad King wrote:
...
> > Currently projects have the option to override it with CMAKE_MODULE_PATH
> > to providing a module with the same API but a tweaked implementation.
> > With the CURRENT_LIST_DIR approach that option goes away, and any
> > project that does it already will break.
>
> Yes, because this option is what makes cmake break KDE currently. This is
> the problem, this is what must be changed.
>
> Nothing breaks with the CURRENT_LIST_DIR, since this only applies to the
> modules shipped with cmake, so those get what they expect.
> The modules shipped with the project still get their own FPHSA.cmake.
> I can't think of a constellation which could break.

Example:
assume a project relies on the fact that FindZLIB.cmake gets their modified 
copy of FPHSA.cmake, which e.g. sets some additional variable, or looks at 
some additional variable (realistically I don't think such a modified 
version, i.e. not just simply an older version, exists).

If we rename the file to FPHSA2.cmake, this will not be the case anymore, so 
their project is broken.
The same happens if FindZLIB.cmake uses CURRENT_LIST_DIR.
Additionally FPHSA2.cmake has other (likely) chances to break in the future 
(see my other email).

Alex