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

[Alexander Neundorf]

On Wednesday 29 September 2010, Eric Noulard wrote:
> Changing subject in order to re-classify the discussion.
>
> 2010/9/28 Brad King <brad.king at kitware.com>:
> > On 09/28/2010 05:20 PM, Alexander Neundorf wrote:
> >> On Tuesday 28 September 2010, Alexander Neundorf wrote:
> >>> Is this intended this way ?
> >>
> >> The attached tiny patch seems to make CMAKE_PARENT_LIST_FILE work more
> >> like I expected.
> >
> > Yes, but who knows what it will break.  I'm not prepared to do
> > this during a release candidate series.
>
> Totally agree with that.
> Moreover I currently lack time for doing fine comments but I think that
> WE MUST not enforce compatibilities between include cmake files in order
> to ensure/enforce consistency between CMake provided files and user
> provided files.
>
> I personally thinks that the current behavior which is to let CMake
> pick-up the first matching file
> from CMAKE_MODULE_PATH is the best one.
>
> Now if ever a project is "forking" one or several
> may-become-incompatible version of CMake provided file(s) then the
> solution shouldn't
> be to burry some absolute path inside CMake provided files.
>
> Being able to "patch" a particular CMake provided include file
> is a feature I want to keep:
>
>    - because user may not be able to wait a new CMake release
>      to get his problem solved
>
>    - because it's perfectly fine to "tune/tweak" CMake provided
>      behavior from within a project

Same here.
But to do this your own module path must be before share/cmake/Modules/, 
otherwise you get the cmake versions of the files.

> My point of view is that this is the project responsible of
> this kind of breakage that should find a fix.

In general I agree.
Still the basic rule is that a new cmake version should never break existing 
builds, which it unfortunately does in this case, even if it's not cmake's 
fault.

Another (also ugly) option would be to blacklist KDE 4.5.0 and 4.5.1 in 
cmake's FindKDE4.cmake, failing with a message like 
"For building KDE 4.5.0/4.5.1 you need cmake < 2.8.3"

At least this would give a proper error message instead of 
"CMake Error at 
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:70 
(MESSAGE):
  REQUIRED_VARS (missing: VERSION_VAR)
Call Stack (most recent call first):"

> For example if the KDE FPHSA was introduced by KDE then
> KDE project should refer (if needed) to the KDE provided FPHSA using
> full path (and not require CMake to do so).

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

Alex