Re: [cmake-developers] find_package error wording
Hi, I must have missed something here. On Friday, February 17, 2012 13:16:42 Brad King wrote: On 2/17/2012 12:09 PM, Alexander Neundorf wrote: But another significant part of the reason is probably that beside upstreaming a module to cmake, there is no other official way to distribute Find- modules. So if somebody wrote a libblub, it is a relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. If the Blub project is built with CMake then there should be no FindBlub for it at all. It should just install BlubConfig.cmake and be done. Perhaps your work to make the files easier to write will help with that. I think this is a good point. The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Good point. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) I'll have to think about how to deal with that. Also relevant. The below seems to be hiding the config files stuff as you wrote. By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Adding the explicit MODULE mode keyword could help with that. - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Yes, exactly. We can adjust it slightly to avoid the policy warning when FooConfig is found and Foo_DIR is set: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path One problem with the policy is that it favors module mode as the normal case and makes config mode look like something special. Yes. That will not help with the perception that the latter is preferred. Yes. However, your suggestion above seems to indicate that that is exactly what's being done? That will make this an error: cmake_required_version(2.8.8) find_package(Qt5Core) Instead this more noisy version would need to be used: cmake_required_version(2.8.8) find_package(Qt5Core CONFIG_MODE) I think that this should work just fine: cmake_required_version(2.8.8) find_package(Qt5Core) And to make Alex's use case satisfied, add a variable for strictness to make this an error: cmake_required_version(2.8.8) set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) find_package(Qt5Core) which Alex can set somewhere in KDE. The main problem is lack of education about config files. That can be solved in the future, so we should make sure that the requirements can be 'clean' for the future. When at some future point KDE developers (and others) are aware of config files, KDE won't need set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) and it can be removed. I prefer KDE to require set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE) rather than changing the default behaviour of CMake (to produce errors) because the former is future proof. 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 error wording
On Sunday 19 February 2012, Stephen Kelly wrote: Hi, I must have missed something here. On Friday, February 17, 2012 13:16:42 Brad King wrote: On 2/17/2012 12:09 PM, Alexander Neundorf wrote: But another significant part of the reason is probably that beside upstreaming a module to cmake, there is no other official way to distribute Find- modules. So if somebody wrote a libblub, it is a relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. If the Blub project is built with CMake then there should be no FindBlub for it at all. It should just install BlubConfig.cmake and be done. Perhaps your work to make the files easier to write will help with that. I think this is a good point. Yes. The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Good point. ...but nobody does it or knows it. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) I'll have to think about how to deal with that. Also relevant. The below seems to be hiding the config files stuff as you wrote. No, by making CONFIG_MODE explicit it is exactly not hidden anymore, but becomes visible. By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Adding the explicit MODULE mode keyword could help with that. - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Yes, exactly. We can adjust it slightly to avoid the policy warning when FooConfig is found and Foo_DIR is set: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path One problem with the policy is that it favors module mode as the normal case and makes config mode look like something special. Yes. Right now the perception is that there is the Module-mode. ...and some people may have heard of some weird config files. Putting both modes on the same level (MODULE_MODE vs. CONFIG_MODE) I hope should help with that. That will not help with the perception that the latter is preferred. Yes. However, your suggestion above seems to indicate that that is exactly what's being done? That will make this an error: cmake_required_version(2.8.8) find_package(Qt5Core) Instead this more noisy version would need to be used: cmake_required_version(2.8.8) find_package(Qt5Core CONFIG_MODE) Yes. And this is good. Then the error message is Could not find config file. Above it has to guess, and the developers will think that FindQt5.cmake is missing. How should they know that Qt5 ships Qt5Config.cmake files ? We always had FindFoo.cmake files for everything, including FindQt4.cmake. They will not think oh, probably a Qt5Config.cmake could not be found. I am 99% sure with this. Somebody complained on google+ that cmake is a mess. If you don't know what to make of an error message, this won't help the perception. I think that this should work just fine: cmake_required_version(2.8.8) find_package(Qt5Core) And to make Alex's use case satisfied, add a variable for strictness to make this an error: cmake_required_version(2.8.8) set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) find_package(Qt5Core) which Alex can set somewhere in KDE. The main problem is lack of education about config files. That can be solved in the future, so we should make sure that the requirements can be 'clean' for the future. When at some future point KDE developers (and others) are aware of config files, KDE won't need set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) and it can be removed. Why push that further into the future, right now where we are about to create dozens of config files ? If we create dozens of config files, developers will see the message could not find Find-module or config file and they will complain that the project is broken because the Find-module is not there. There is the policy mechanism exactly for that, no need to introduce new global variables. If you don't want to see the warning, set CMP0018 to OLD,
Re: [cmake-developers] find_package error wording
On Sunday, February 19, 2012 16:18:00 Alexander Neundorf wrote: On Sunday 19 February 2012, Stephen Kelly wrote: The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Good point. ...but nobody does it or knows it. Not many KDE developers at least. But KDE developers aren't really known for CMake knowledge anyway. They generally get exposed to as little CMake as possible, so I'm not sure they make a good target usecase. However, your suggestion above seems to indicate that that is exactly what's being done? That will make this an error: cmake_required_version(2.8.8) find_package(Qt5Core) Instead this more noisy version would need to be used: cmake_required_version(2.8.8) find_package(Qt5Core CONFIG_MODE) Yes. And this is good. I disagree :) Then the error message is Could not find config file. Above it has to guess, and the developers will think that FindQt5.cmake is missing. How should they know that Qt5 ships Qt5Config.cmake files ? feature_summary() should tell them that they have to install the development package for Qt5. Whether they need a Find module or a Config file, they still need to install that, so they might as well do it first. We always had FindFoo.cmake files for everything, including FindQt4.cmake. They will not think oh, probably a Qt5Config.cmake could not be found. I am 99% sure with this. Somebody complained on google+ that cmake is a mess. If you don't know what to make of an error message, this won't help the perception. Without knowing what specifically they think is a mess, I don't know. I expect that wasn't part of the + post. Specifics rarely are :) Just yesterday when I was trying to build parts of kdelibs, and got all the complaints that neither a Find-module could be found nor a config-file could be found, I completely didn't know what the right way to fix them is. Is the Find-module missing, and I should add it, or is the package missing, because it should have installed a config file. It is usually easy at least with a package manager too see if libfoo-dev is installed. That at least reduces the scope of the error to either CMake not finding the config file (unlikely if a distro package is used, and if you installed it yourself then you might know if you installed it) or requiring a FindFoo.cmake in your CMAKE_MODULE_PATH (and then you have to figure out where it should come from). I would have to check the sources of each of the missing packages to figure out whether it installs a config file or not. Making this explicit helps. This will also help in making the Config mode more visible, since it will not be hidden anymore. You know, people will see find_package(Qt5 CONFIG_MODE) and they might have a look what that CONFIG_MODE means. Without it, they won't. Maybe. The current branch isn't my preferred solution. Even after everyone has a firm understanding of what CONFIG_MODE means, we'll still always need it. Maybe another policy in the future would be able to make it the default? I don't know if there's a better solution, but I just wanted to raise my concerns. 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 error wording
On Sunday 19 February 2012, Stephen Kelly wrote: On Sunday, February 19, 2012 16:18:00 Alexander Neundorf wrote: On Sunday 19 February 2012, Stephen Kelly wrote: The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Good point. ...but nobody does it or knows it. Not many KDE developers at least. But KDE developers aren't really known for CMake knowledge anyway. They generally get exposed to as little CMake as possible, so I'm not sure they make a good target usecase. Since 6 years KDE developers are my daily target usecase. I think they are the biggest existing group of cmake users out there. I don't think they are very different from other users. Also, what I always tried to do is to hide as little cmake stuff from them as possible. It shouldn't be seen as magic what is happening. All the macros etc. I wrote try to be in the same style as the original cmake commands. Look at how boost is using cmake. They are hiding it. Almost completely. I don't like how they use it. Because their users won't have a clue about cmake. However, your suggestion above seems to indicate that that is exactly what's being done? That will make this an error: cmake_required_version(2.8.8) find_package(Qt5Core) Instead this more noisy version would need to be used: cmake_required_version(2.8.8) find_package(Qt5Core CONFIG_MODE) Yes. And this is good. I disagree :) Then the error message is Could not find config file. Above it has to guess, and the developers will think that FindQt5.cmake is missing. How should they know that Qt5 ships Qt5Config.cmake files ? feature_summary() should tell them that they have to install the development package for Qt5. Whether they need a Find module or a Config file, they still need to install that, so they might as well do it first. Maybe they have already installed it, so they now think a FindQt5.cmake file is missing. It is good to have precise error messages. We always had FindFoo.cmake files for everything, including FindQt4.cmake. They will not think oh, probably a Qt5Config.cmake could not be found. I am 99% sure with this. Somebody complained on google+ that cmake is a mess. If you don't know what to make of an error message, this won't help the perception. Without knowing what specifically they think is a mess, I don't know. I expect that wasn't part of the + post. Specifics rarely are :) Just yesterday when I was trying to build parts of kdelibs, and got all the complaints that neither a Find-module could be found nor a config-file could be found, I completely didn't know what the right way to fix them is. Is the Find-module missing, and I should add it, or is the package missing, because it should have installed a config file. It is usually easy at least with a package manager too see if libfoo-dev is installed. That at least reduces the scope of the error to either CMake not finding the config file (unlikely if a distro package is used, and if you See, and with the policy the scope is 100% reduced. Then I know what's wrong. installed it yourself then you might know if you installed it) or requiring a FindFoo.cmake in your CMAKE_MODULE_PATH (and then you have to figure out where it should come from). I would have to check the sources of each of the missing packages to figure out whether it installs a config file or not. Making this explicit helps. This will also help in making the Config mode more visible, since it will not be hidden anymore. You know, people will see find_package(Qt5 CONFIG_MODE) and they might have a look what that CONFIG_MODE means. Without it, they won't. Maybe. The current branch isn't my preferred solution. Even after everyone has a firm understanding of what CONFIG_MODE means, we'll still always need it. Yes. I don't see a problem with needing an additional keyword. This is what has happened with more or less all cmake commands: in the beginning they had simply a list of arguments, now most of them have two modes, the old one, and a new one which is a bit more verbose and more powerful. Compare find_package(Qt5) vs. find_package(Qt5 CONFIG_MODE) IMO here it's completely in your face that I want a config file. The much better error message is IMO absolutely worth the one extra argument. Now and also in the future. 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:
Re: [cmake-developers] find_package error wording
On Friday 17 February 2012, Alexander Neundorf wrote: On Friday 17 February 2012, Brad King wrote: On 2/17/2012 5:05 PM, Alexander Neundorf wrote: I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking backward compatibility of users projects (not cmake) this way. We can add them and document them in the new version but not mention them in error messages for now. This is what I have so far: --- policy NEW, Find-module not found: This is now in the branch FindPackage_MODULE_MODE_Policy on stage. I still have to add tests. I wrote documentation for the new CMP0018. For find_package(), I think the whole first part of the documentation has to be modified. Currently it says: User code should generally look for packages using the above simple signature. The remainder of this command documentation specifies the full command signature and details of the search process. Project maintainers wishing to provide a package to be found by this command are encouraged to read on. 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. 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 error wording
On Friday 17 February 2012, Alexander Neundorf wrote:
On Friday 17 February 2012, Brad King wrote:
...
Perhaps we can make the distinction between user and developer right
in the message. When there is no Find module the proper message that
a user sees should talk about ecm_DIR and CMAKE_PREFIX_PATH only.
This should be the focus. We can then add an extra note to help
developers use Find modules. Consider:
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 you are a developer expecting this find_package to load a
Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)
I'm still not convinced.
Just today I found this commit from last October in kdelibs:
http://quickgit.kde.org/index.php?p=kdelibs.gita=commitdiffh=ca501aa9f4c1
e7adcd42accbd53538502ba50ce3hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655
Commit message: on win32 we need access to the installed cmake modules dir
--- a/cmake/modules/FindKDE4Internal.cmake
+++ b/cmake/modules/FindKDE4Internal.cmake
@@ -736,6 +736,7 @@ endif(${CMAKE_MAJOR_VERSION}.${CMAKE_MIN
option(KDE4_ENABLE_FPIE Enable platform supports PIE linking)
if (WIN32)
+ list(APPEND CMAKE_MODULE_PATH
${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules)
find_package(KDEWin REQUIRED)
option(KDE4_ENABLE_UAC_MANIFEST add manifest to make... OFF)
if (KDE4_ENABLE_UAC_MANIFEST)
This looks really wrong (I mean this directory is not guaranteed to exist
at all at cmake time, so it can't help finding a module file), and it was
committed by a developer who is using cmake now already since 2006 at
least.
If I would build this, I would get exactly to case 1) - neither Find-module
nor config-file found.
As user I should assume that there should be a config file, and I should
install the package or set CMAKE_PREFIX_PATH. But this wouldn't help,
because actually the Find-module is missing, because in some way the
buildsystem expects something wrong.
So when I (as user) would assume the package is not installed because the
config has not been found, I would be wrong, but I couldn't see this from
the code.
If config-file searching would have to be enabled, I would know from the
error message (which would then say Find-module not found) that the
buildsystem is broken, and not some package is missing or
CMAKE_PREFIX_PATH is not set.
IOW: it's a quite common error to install a FindFoo.cmake as part of the
package Foo into the prefix where foo is installed.
So if cmake knows that really the Find-module should have been found, it can
produce a very clear error message that the missing Find-module must be part
of the project itself or provided by another previously found package, and
that the buildsystem is broken.
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 error wording
On 2/17/2012 11:37 AM, Alexander Neundorf wrote: developers use Find modules. Consider: 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 you are a developer expecting this find_package to load a Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.) I'm still not convinced. Convinced of what? I'm suggesting alternative wording for a change you just committed yourself. Whether to introduce the policy is another decision which should be resolved before any changes for this end up in master. IOW: it's a quite common error to install a FindFoo.cmake as part of the package Foo into the prefix where foo is installed. Any suggestion how to correct this misconception? There is no place in any of our documentation or tutorials on the wiki that suggests it. So if cmake knows that really the Find-module should have been found, it can produce a very clear error message that the missing Find-module must be part of the project itself or provided by another previously found package, and that the buildsystem is broken. This discussion relates to the introduction of the policy you proposed. Please comment on my question from yesterday: On 2/16/2012 11:57 AM, Brad King wrote: So your proposal when no extra find_package mode arg is given is: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path ? Separately the CONFIG and MODULE explicit mode args can be given to be alternative to NO_MODULE. -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 error wording
On Friday 17 February 2012, Brad King wrote: On 2/17/2012 11:37 AM, Alexander Neundorf wrote: developers use Find modules. Consider: 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 you are a developer expecting this find_package to load a Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.) I'm still not convinced. Convinced of what? I'm suggesting alternative wording for a change you just committed yourself. Not convinced that splitting the error message this way is appropriate, and also not convinced that it is good that config-files are searched also without NO_MODULE. Whether to introduce the policy is another decision which should be resolved before any changes for this end up in master. IOW: it's a quite common error to install a FindFoo.cmake as part of the package Foo into the prefix where foo is installed. Any suggestion how to correct this misconception? There is no place in any of our documentation or tutorials on the wiki that suggests it. I may be part of the problem. We install a lot of Find-modules with kdelibs, so developers got the impression that this is a good thing to do, so they do this now too for their libraries. But another significant part of the reason is probably that beside upstreaming a module to cmake, there is no other official way to distribute Find- modules. So if somebody wrote a libblub, it is a relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) (But what I did never do is to install FindKDE4.cmake as part of kdelibs, FindKDE4.cmake comes with cmake, so that is fine. And once you found kdelibs, it is ok to use the modules installed by kdelibs.) By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Did not find FindFoo.cmake. FindFoo.cmake must either be part of the project itself, in this case adjust CMAKE_MODULE_PATH so that it points to the correct location inside your source tree. Or it must be installed by a package which has already been found via find_package(). In this case make sure that this package has indeed been found and adjust CMAKE_MODULE_PATH to contain the location where that package has installed FindFoo.cmake. This must be a variable provided by that package. If you are developer of the current project, go fix your buildsystem ! If you are only building this project, tell the developers to fix their buildsystem ! Well, something like this. ;-) So if cmake knows that really the Find-module should have been found, it can produce a very clear error message that the missing Find-module must be part of the project itself or provided by another previously found package, and that the buildsystem is broken. This discussion relates to the introduction of the policy you proposed. Please comment on my question from yesterday: On 2/16/2012 11:57 AM, Brad King wrote: So your proposal when no extra find_package mode arg is given is: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path ? Separately the CONFIG and MODULE explicit mode args can be given to be alternative to NO_MODULE. Yes, exactly. I think I didn't answer explicitely because it seemed clear to me that this is exactly what I meant :-) 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 error wording
On Friday 17 February 2012, Alexander Neundorf wrote: ... But another significant part of the reason is probably that beside upstreaming a module to cmake, there is no other official way to distribute Find- modules. So if somebody wrote a libblub, it is a relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. I did not make that up, this email from Pau on the buildsystem list just arrived after I sent this email here: http://lists.kde.org/?l=kde-buildsystemm=132949736429566w=2 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 error wording
On 2/17/2012 12:09 PM, Alexander Neundorf wrote: But another significant part of the reason is probably that beside upstreaming a module to cmake, there is no other official way to distribute Find- modules. So if somebody wrote a libblub, it is a relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. If the Blub project is built with CMake then there should be no FindBlub for it at all. It should just install BlubConfig.cmake and be done. Perhaps your work to make the files easier to write will help with that. The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) I'll have to think about how to deal with that. By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Adding the explicit MODULE mode keyword could help with that. - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Yes, exactly. We can adjust it slightly to avoid the policy warning when FooConfig is found and Foo_DIR is set: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path One problem with the policy is that it favors module mode as the normal case and makes config mode look like something special. That will not help with the perception that the latter is preferred. -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 error wording
On Friday 17 February 2012, Brad King wrote: On 2/17/2012 12:09 PM, Alexander Neundorf wrote: But another significant part of the reason is probably that beside upstreaming a module to cmake, there is no other official way to distribute Find- modules. So if somebody wrote a libblub, it is a relatively obvious choice to install FindBlub.cmake as part of the library, so that whoever uses Blub, also has FindBlub.cmake available. If the Blub project is built with CMake then there should be no FindBlub for it at all. It should just install BlubConfig.cmake and be done. Perhaps your work to make the files easier to write will help with that. Yes, but people do that all the time. I think I saw this for more or less every library which was written in KDE, and whenever I saw it I explained that distributing the Find-module together with the library doesn't make sense. I'm sure I didn't get all cases. The only reason to distribute FindBlub for a CMake-aware project is to wrap up find_package NO_MODULE to produce a nicer message, but that is totally optional. If a project does want to distribute one for reference it should go in the -doc package, not in -dev, and should be put in share/doc/blub or the distro's equivalent. Additionally, the Config.cmake file feature of cmake is still relatively unknown. It could use some more PR ;-) I'll have to think about how to deal with that. By having to use NO_MODULE, or the other way round, if by not using NO_MODULE it is clear to cmake that a Find-module is needed, it could then print something like: Adding the explicit MODULE mode keyword could help with that. - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, warn and follow OLD behavior - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Yes, exactly. We can adjust it slightly to avoid the policy warning when FooConfig is found and Foo_DIR is set: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Just to make sure I understand: behave as described intially, but don't warn if the config file has been found via Foo_DIR. Right ? Ok with me. One problem with the policy is that it favors module mode as the normal case and makes config mode look like something special. That will not help with the perception that the latter is preferred. I actually prefer to have a simple 3 line wrapper Find-module within the project: FindFoo.cmake: find_package(Foo NO_MODULE) fphsa(Foo CONFIG_MODE) set_package_feature(Foo PROPERTIES PURPOSE Enables something in this app TYPE RECOMMENDED URL http://www.foo.org ) so people get a nice short result line during the cmake run and an informative summary at the end of the cmake run via FeatureSummary.cmake 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 error wording
On 2/17/2012 1:28 PM, Alexander Neundorf wrote: We can adjust it slightly to avoid the policy warning when FooConfig is found and Foo_DIR is set: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Just to make sure I understand: behave as described intially, but don't warn if the config file has been found via Foo_DIR. Right ? Ok with me. Yes. That will avoid unnecessary policy warnings when things work. Please push a proposed implementation to the stage for review. The documentation of the policy will have a lot of history to explain this. 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
Re: [cmake-developers] find_package error wording
On Friday 17 February 2012, Brad King wrote: On 2/17/2012 1:28 PM, Alexander Neundorf wrote: We can adjust it slightly to avoid the policy warning when FooConfig is found and Foo_DIR is set: - search for FindFoo.cmake, use if found - if not found, check new policy setting - if not set, enter config mode and emit both the policy warning and the current error if not found - if set to OLD, enter config mode and use current error if not found - if set to NEW, present error about no FindFoo in module path Just to make sure I understand: behave as described intially, but don't warn if the config file has been found via Foo_DIR. Right ? Ok with me. Yes. That will avoid unnecessary policy warnings when things work. Please push a proposed implementation to the stage for review. The documentation of the policy will have a lot of history to explain this. Ok :-) Should I do this by continuing in the FindPackage_ImprovedErrorMessages branch or create a new branch, branched away from FindPackage_ImprovedErrorMessages ? 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 error wording
On Friday 17 February 2012, Alexander Neundorf wrote: ... Ok :-) Should I do this by continuing in the FindPackage_ImprovedErrorMessages branch or create a new branch, branched away from FindPackage_ImprovedErrorMessages ? I create a new branch. Do you want me to add the new keywords ? NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE 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 error wording
On 2/17/2012 2:01 PM, Alexander Neundorf wrote: Do you want me to add the new keywords ? NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE Yes, but I don't think NO_CONFIG_MODE is necessary. NO_MODULE will become historical. Let's make the new ones consistent with each other: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. Then the policy can be added on top of it as a new topic. 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
Re: [cmake-developers] find_package error wording
On Friday 17 February 2012, Brad King wrote: On 2/17/2012 2:01 PM, Alexander Neundorf wrote: Do you want me to add the new keywords ? NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE Yes, but I don't think NO_CONFIG_MODE is necessary. NO_MODULE will become historical. Let's make the new ones consistent with each other: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, which has IMO only uncontroversial fixes to the error messages and a small bugfix. Ok ? (since I merged this already into next, and I have never undone such a merge yet) 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 error wording
On 2/17/2012 2:16 PM, Alexander Neundorf wrote: On Friday 17 February 2012, Brad King wrote: On 2/17/2012 2:01 PM, Alexander Neundorf wrote: Do you want me to add the new keywords ? NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE Yes, but I don't think NO_CONFIG_MODE is necessary. NO_MODULE will become historical. Let's make the new ones consistent with each other: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, which has IMO only uncontroversial fixes to the error messages and a small bugfix. Ok ? (since I merged this already into next, and I have never undone such a merge yet) Okay. The messages will be tweaked again by the new modes though. -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 error wording
On Friday 17 February 2012, Brad King wrote: On 2/17/2012 2:16 PM, Alexander Neundorf wrote: On Friday 17 February 2012, Brad King wrote: On 2/17/2012 2:01 PM, Alexander Neundorf wrote: Do you want me to add the new keywords ? NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE Yes, but I don't think NO_CONFIG_MODE is necessary. NO_MODULE will become historical. Let's make the new ones consistent with each other: CONFIG_MODE MODULE_MODE The names have clear mapping to the documented modes. This change can be made first with documentation and tests. I'd like to review and accept that change first. I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, which has IMO only uncontroversial fixes to the error messages and a small bugfix. Ok ? (since I merged this already into next, and I have never undone such a merge yet) Okay. The messages will be tweaked again by the new modes though. There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the two keywords, but doesn't change the behaviour yet. So there wasn't a lot to change in the documentation or tests. I'll do the modified behaviour together with the policy. 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 error wording
On 2/17/2012 4:01 PM, Alexander Neundorf wrote: There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the two keywords, but doesn't change the behaviour yet. So there wasn't a lot to change in the documentation or tests. I'll do the modified behaviour together with the policy. Looks good. 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
Re: [cmake-developers] find_package error wording
On Friday 17 February 2012, Brad King wrote: On 2/17/2012 4:01 PM, Alexander Neundorf wrote: There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the two keywords, but doesn't change the behaviour yet. So there wasn't a lot to change in the documentation or tests. I'll do the modified behaviour together with the policy. Looks good. I'm just implementing the warnings There is a problem with the new keywords. If I make the warning ... use the CONFIG_MODE keyword ... and the developer does this then, then his project will not work anymore with older cmake versions, because they don't know CONFIG_MODE. If the warning says instead ... use the NO_MODULE keyword ... then the project will still work with old and new cmake versions correctly. I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking backward compatibility of users projects (not cmake) this way. 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 error wording
On 2/17/2012 5:05 PM, Alexander Neundorf wrote: I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking backward compatibility of users projects (not cmake) this way. We can add them and document them in the new version but not mention them in error messages for now. -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
