[cmake-developers] find_package error wording

[Alexander Neundorf]

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