Re: [cmake-developers] User vs CMake include mismatch handling [was CMake 2.8.3-rc1 ready for testing!]
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. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] User vs CMake include mismatch handling [was CMake 2.8.3-rc1 ready for testing!]
Changing subject in order to re-classify the discussion. 2010/9/28 Brad King brad.k...@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 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
