[Development] Qt5*Config.cmake files: _qt5_*_check_file_exists macros and plugins

[Stephen Kelly]

Kevin Kofler wrote:

> 
> Those _qt5_*_check_file_exists checks look unnecessary to me in the first
> place.

Part of the intention of the way CMake config-packages and IMPORTED targets 
work is that if the FooConfig.cmake is present and found, and the Foo 
IMPORTED target is present, then you can use it without further checks.

 http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html

> * If a file is NOT actually required to build against the library, then it
>   should NOT be checked for (as is the case for those plugins).

The intention of the check is to verify that the things defined/"exported" 
by the package actually exist - it's not about whether the files are 
required to build against the library, per se. That's not the intention of 
the check.

> But I also don't see the checks being useful for self-built Qt (where
> "make install" will just install everything) nor your upstream binaries
> (which also contain everything that is needed).

1) If I reference a plugin in my buildsystem (so I can make a mac bundle or 
whatever), and I have not installed the Fedora package for the plugin, 
things might seem fine in the buildsystem, but the plugin won't be packaged, 
and I'll have runtime bugs to debug. The check turns that into a build-time 
report.

2) Other people can also create packages for use within an organization, and 
they may not do it right, may not have the rules/guarantees that you provide 
with your packages etc.

In saying that though, the check is probably relatively low value.

> So the question there is:
> Why were those checks added in the first place? Can they be removed in
> upstream Qt?

My suggestion is similar to the idea behind 

 https://codereview.qt-project.org/61334

Namely, add a component to the *Config.cmake packages such that the user can 
write 

 find_package(Qt5Core REQUIRED Plugins)

to express that the plugins are needed in the buildsystem (for whatever 
reason).

The semantic might be, 

* if the Plugins component is specified, then check for existence, otherwise 
don't.

or

* if the Plugins component is specified, then load the *PluginConfig.cmake 
files, otherwise don't. This has the side-effect that the existence check 
won't be done.

I prefer the second option (and there may be more options). The problem is 
backward compatibility though - currently people are not specifying the 
Plugins component and the plugin IMPORTED targets are defined and usable. 
After such a change they wouldn't be. However, users would have to update 
their Qt to get the new behavior and it would be immediately noticable, and 
maybe something like a CMake policy could be emulated for it. 

So I think that would be ok. What do you think? Then, afaiu, you could 
continue to ship the *Config.cmake files in your -devel package, but they 
won't cause a fatal error if the plugin is not present, unless the user 
specifies that they want the plugin, and then the fatal error is 
appropriate.

>    3.b. One subpackage per *Plugin.cmake file, i.e. for every
>         qt5-modulename-pluginname package, we'd have a
>         qt5-modulename-pluginname-devel. That means many subpackages.

This looks to me like the most correct but probably least convenient 
solution.

Thanks,

Steve.