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

[Eric Noulard]

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

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

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

As Alex saif before:
>> I don't think it's a good idea.
>> People may purposely want to override CMake provided module
>> in order to implement specific behavior and/or to patch locally.

> This is what we do in KDE, and I think it would be good for us.

> Using
> include(FPHSA CURRENT_DIR)
> in the files in cmake would mean that the find-modules in cmake also get the
> FPHSA they expect to get, and if we would use that in KDE too, we would be
> sure we would get our modified version.

Again, my opinion is: KDE may ask to explicitely load its own FPHSA but
shall not require the CMake provided modules to explicitely load the
CMake provided one.

May be an "ORIGIN" property may be automatically added to a MACRO
in order to be able to check whether the macros comes from CMake or
from a User provided file.

Then you may implement your guard using:

if (COMMAND FIND_PACKAGE_HANDLE_STANDARD_ARGS)
    get_property(FPHSA_ORIGIN COMMAND PROPERTY ORIGIN)
    if (FPHSA_ORIGIN STREQUAL "CMake")
       include(/absolute/path/to/my/FPHSA)
    endif(FPHSA_ORIGIN STREQUAL "CMake")
endif(COMMAND FIND_PACKAGE_HANDLE_STANDARD_ARGS)

the "ORIGIN" property may be set automatically by CMake
(to "User" or "CMake") when loading a cmake file.

using this "kind of trick" the guard may be more "intelligent"
and check what to do depending on CMAKE_xxx_VERSION.

I know that this is NOT solving the current KDE problem
but as stated before may be if we "fix" the KDE problem by
enforcing absolute path include within CMake some other
projects will break in another way?

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org