[cmake-developers] find_package error wording

Stephen Kelly steveire at gmail.com
Sun Feb 19 09:46:13 EST 2012


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.





More information about the cmake-developers mailing list