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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
