[cmake-developers] find_package error wording

[Alexander Neundorf]

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, no change in 
behaviour then.


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

No, if done with a policy, it is future proof.

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.
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.
Just look at the current discussions on kde-buildsystem.

Alex