Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On Monday 20 February 2012, Alexander Neundorf wrote: On Monday 20 February 2012, Brad King wrote: ... (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. (3) Add two possible AUTHOR_WARNING messages in the case that no mode keyword or Find module is present: - If the current minimum CMake required version is = 2.8.8 then warn that MODULE or CONFIG should be used. - Otherwise if CMAKE_FIND_PACKAGE_WARN_NO_MODULE is set to true then warn that NO_MODULE should be used to get the config mode. There is now a branch FindPackage_ModeWarning on stage. I should have probably pushed all my commits to this branch... Done now. Working on your suggestions. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On Tuesday 21 February 2012, Alexander Neundorf wrote: On Monday 20 February 2012, Alexander Neundorf wrote: On Monday 20 February 2012, Brad King wrote: ... (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. (3) Add two possible AUTHOR_WARNING messages in the case that no mode keyword or Find module is present: - If the current minimum CMake required version is = 2.8.8 then warn that MODULE or CONFIG should be used. - Otherwise if CMAKE_FIND_PACKAGE_WARN_NO_MODULE is set to true then warn that NO_MODULE should be used to get the config mode. There is now a branch FindPackage_ModeWarning on stage. I should have probably pushed all my commits to this branch... Done now. Working on your suggestions. Problem ? Somebody has a FindConfig.cmake here: http://lists.gforge.inria.fr/pipermail/blobseer-commits/2009- January/000101.html There may be also a FindCONFIG.cmake or a FindMODULE.cmake somewhere... Even so with FindConfig.cmake, if this runs on Windows, they might be doing find_package(CONFIG REQUIRED) Now it searches for the required package FindCONFIG.cmake. Then it would search for REQUIREDConfig.cmake... Using the next argument only as package name if it is not a known keyword or version number would lead to even more non-working package names: HINTS, PATHS, CONFIGS, 123, REQUIRED, COMPONENTS, NAMES (I left all keywords which have an underscore out, it is probably too unlikely that there is a FindPATH_SUFFIXES.cmake). Ignore and just hope it will be ok ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On 2/19/2012 10:54 AM, Alexander Neundorf wrote: I don't see a problem with needing an additional keyword. find_package(Qt5) vs. find_package(Qt5 CONFIG_MODE) Remember we decided on find_package(Qt5 CONFIG) instead which reads better. I'm not opposed outright to this syntax in the future. However, I think the policy as proposed is too aggressive for transition. It will create a warning on every config-mode find_package call that exists in any project release to date. This penalizes everyone who was proactive enough to have read, understood, and used the more powerful config-mode. The warning will remain in all the old releases of their projects forever and make it look like they did something wrong. Furthermore, to avoid the warning in new versions they will have to add extra decoration to their calls, and during the transition period that decoration will be spelled NO_MODULE which is pretty ugly when not in a Find module. -- We need a smoother transition plan. It must not create warnings in old projects. Here is a plan I can accept: (1) Improve the current ambiguous error message (see below). (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. (3) Add two possible AUTHOR_WARNING messages in the case that no mode keyword or Find module is present: - If the current minimum CMake required version is = 2.8.8 then warn that MODULE or CONFIG should be used. - Otherwise if CMAKE_FIND_PACKAGE_WARN_NO_MODULE is set to true then warn that NO_MODULE should be used to get the config mode. The first one will not appear in old projects but will become more common over time. The second one can be used in projects (KDE) to get the warning even before bumping the min required version to 2.8.8. In either case the warning should appear even when the package configuration file is found. This will convince developers to add the keyword because it is required to avoid the warning. (4) In the future, e.g. CMake 3.0.0, add the policy if necessary. At that point it will be able to leverage the new features added above so that the NEW behavior is clean. -- Now to improve the error message (step 1 above). The current ambiguous error message originated here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53d9d84f Prior to that it only talked about the package config file. It was only in an attempt to help developers debug their CMAKE_MODULE_PATH that the ambiguous message was added, but at the cost of making it unclear to users what is needed. The message needs to be clear to users and developers, but with a preference for users because it will appear even in properly written projects when the package config file is not found. We can extend what I previously proposed: CMake Error at CMakeLists.txt:7 (find_package): No package configuration file for ecm found by names: ecmConfig.cmake ecm-config.cmake Add the installation prefix of ecm to CMAKE_PREFIX_PATH or set ecm_DIR to a directory containing one of the above files. If ecm provides separate development package or SDK be sure it has been installed. If ecm does not provide a package configuration file then this project must ensure that a Findecm.cmake module lies in its CMAKE_MODULE_PATH before calling find_package. The last paragraph should not appear with NO_MODULE or CONFIG. If no Find module is available but MODULE was used then one can write a very detailed message about setting CMAKE_MODULE_PATH. The future policy in step 4 above can make this the default in its NEW behavior. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
Brad King wrote: On 2/19/2012 10:54 AM, Alexander Neundorf wrote: I don't see a problem with needing an additional keyword. find_package(Qt5) vs. find_package(Qt5 CONFIG_MODE) Remember we decided on find_package(Qt5 CONFIG) instead which reads better. I'm not opposed outright to this syntax in the future. However, I think the policy as proposed is too aggressive for transition. It will create a warning on every config-mode find_package call that exists in any project release to date. This penalizes everyone who was proactive enough to have read, understood, and used the more powerful config-mode. The warning will remain in all the old releases of their projects forever and make it look like they did something wrong. Furthermore, to avoid the warning in new versions they will have to add extra decoration to their calls, and during the transition period that decoration will be spelled NO_MODULE which is pretty ugly when not in a Find module. The discussion on the KDE buildsystem list to addresses some deeper frustrations with the way CMake finds packages, including modifying the cache through CMake-gui where to find things in the case that Find modules are used: http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7065/focus=7124 Could be useful for your consideration. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On Monday 20 February 2012, Brad King wrote: ... (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. Should it only warn if no mode keyword is used, or should it also warn if NO_MODULE is used ? The behaviour without keyword would stay unchanged, i.e. first Find-modules, the config files ? MODULE mode would be only Find-modules, no config files ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On Monday 20 February 2012, Brad King wrote: On 2/19/2012 10:54 AM, Alexander Neundorf wrote: I don't see a problem with needing an additional keyword. find_package(Qt5) vs. find_package(Qt5 CONFIG_MODE) Remember we decided on find_package(Qt5 CONFIG) instead which reads better. I don't have a strong opinion on this, but I'd prefer CONFIG_MODE over CONFIG for two reasons: * find_package_handle_standard_args() already knows the keyword CONFIG_MODE, so I wouldn't introduce a second similar but slightly different keyword to mean the same * CONFIG_MODE is more different from CONFIGS than CONFIG I'm not opposed outright to this syntax in the future. However, I think the policy as proposed is too aggressive for transition. It will create a warning on every config-mode find_package call that exists in any project release to date. This penalizes everyone who was proactive enough to have read, understood, and used the more powerful config-mode. The warning will remain in all the old releases of their projects forever and make it look like they did something wrong. Furthermore, to avoid the warning in new versions they will have to add extra decoration to their calls, and during the transition period that decoration will be spelled NO_MODULE which is pretty ugly when not in a Find module. -- We need a smoother transition plan. It must not create warnings in old projects. Here is a plan I can accept: (1) Improve the current ambiguous error message (see below). I don't think the modified message changes anything significantly (see below). (2) Add the explicit MODULE and CONFIG mode keywords. Warn if they are used and the current minimum CMake version is not = 2.8.8 so that people do not add them in places that will break old versions. (3) Add two possible AUTHOR_WARNING messages in the case that no mode keyword or Find module is present: - If the current minimum CMake required version is = 2.8.8 then warn that MODULE or CONFIG should be used. - Otherwise if CMAKE_FIND_PACKAGE_WARN_NO_MODULE is set to true then warn that NO_MODULE should be used to get the config mode. There is now a branch FindPackage_ModeWarning on stage. It is branched away from the FindPackage_CONFIG_MODE_MODULE_MODE branch. - default mode is unchanged. - MODULE_MODE uses only the Find-modules - NO_MODULE == CONFIG_MODE uses only the config files. - warning messages are printed, but they are not finished, to say the least It warns if: * the required version is 2.8.8, and MODULE_MODE or CONFIG_MODE has been used * the required version is 2.8.8, CMAKE_FIND_PACKAGE_WARN_NO_MODULE is TRUE, no Find-module has been found and NO_MODULE has not been used * the required version is = 2.8.8, no Find-module has been found, and no mode keyword has been used Is that what you meant ? The first one will not appear in old projects but will become more common over time. The second one can be used in projects (KDE) to get the warning even before bumping the min required version to 2.8.8. In either case the warning should appear even when the package configuration file is found. This will convince developers to add the keyword because it is required to avoid the warning. (4) In the future, e.g. CMake 3.0.0, add the policy if necessary. At that point it will be able to leverage the new features added above so that the NEW behavior is clean. If there is always a warning when no mode keyword is used, I think this may not be necessary. -- Now to improve the error message (step 1 above). The current ambiguous error message originated here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53d9d84f Prior to that it only talked about the package config file. It was only in an attempt to help developers debug their CMAKE_MODULE_PATH that the ambiguous message was added, but at the cost of making it unclear to users what is needed. Ok, so I added the message :-) And I still think the error message as it is (in the branch), is correct, it doesn't *create* any ambiguity. All it does is, it explains the actual situation to the user. The problem that it is unclear to the user (and to cmake) what is needed, is already there, because due to the automatic fallback it actually is unclear what is needed. The message needs to be clear to users and developers, but with a preference for users because it will appear even in properly written projects when the package config file is not found. We can extend what I previously proposed: CMake Error at CMakeLists.txt:7 (find_package): No package configuration file for ecm found by names: ecmConfig.cmake ecm-config.cmake Add the installation prefix of ecm to CMAKE_PREFIX_PATH or set ecm_DIR to a directory containing one of the
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On 2/18/2012 10:43 AM, Alexander Neundorf wrote: This is now in the branch FindPackage_MODULE_MODE_Policy on stage. I still have to add tests. Thanks for the prototype. I'm not promising acceptance yet but it is a good reference for discussion. I'm going to continue the discussion over on Stephen's response in this thread. I think with this new policy MODULE_MODE should not be considered the simple signature and NO_MODULE the full signature anymore, but both with equal rights. It used to be one signature but IIRC you asked me to break out the reduced signature since that is all people need most of the time. After thinking about the new _MODE options more I think calling them just MODULE and CONFIG is better. The former is very clearly the opposite of NO_MODULE, and the latter reads well: find_package(Foo CONFIG) # find Foo's package config file I do not think the similarity of CONFIG to the existing CONFIGS is a problem because the latter implies the former anyway so they never need to be used at the same time. The latter reads well too: find_package(Foo CONFIGS FooConfig.cmake) # (Finds FooConfig.cmake from package Foo) # (CONFIGS is similar to NAMES in find_library) -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On 2/17/2012 1:54 PM, Alexander Neundorf wrote: Should I do this by continuing in the FindPackage_ImprovedErrorMessages branch or create a new branch, branched away from FindPackage_ImprovedErrorMessages ? The messages will probably be all different with the policy. Let's start a new one for this change and revert the current branch to avoid conflicts. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
