Fix usage of query_qmake: differ between calls expecting qmake or not
ClosedPublic

Authored by kossebau on Jul 18 2017, 4:37 PM.

Details

Summary

when KDE_INSTALL_USE_QT_SYS_PATHS has been explicitely set,
qmake can be considered a required dependency, otherwise the
paths will not be known, which would be unexpected.
Also does the code calling query_qmake, besides the one testing
for the same install prefix, not handle the case of empty strings
being returned and then results in bogus behaviour.

Thus this patch makes code fail hard if query_qmake is expected
to yield a result, but no qmake executable is found.

Diff Detail

Repository
R240 Extra CMake Modules
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
kossebau created this revision.Jul 18 2017, 4:37 PM
Restricted Application added projects: Frameworks, Build System. · View Herald TranscriptJul 18 2017, 4:37 PM
Restricted Application added a subscriber: Build System. · View Herald Transcript

See also D6773 for making the resulting behaviour documented.

apol edited edge metadata.Jul 19 2017, 1:13 PM

What's the background for the change?

modules/ECMQueryQmake.cmake
25–31

Use cmake_parse_arguments

In D6772#126799, @apol wrote:

What's the background for the change?

When KDE_INSTALL_USE_QT_SYS_PATHS is explicitely set to ON but no qmake-qt5 executable found (like @rdieter reported to be possible on fedora packaging), query_qmake will only emit a warning and then return an empty string.
Just, e.g. KDEInstallDirs code does not check for that empty string/error, but assumes a proper value to be returned when using it for estimating the Qt system paths, e.g. like this:

query_qmake(qt_plugins_dir QT_INSTALL_PLUGINS)

_define_absolute(QTPLUGINDIR ${qt_plugins_dir}
    "Qt plugins"
     QT_PLUGIN_INSTALL_DIR)

And given there is no sane default here, but instead we expect to get the paths from qmake, these kinds of calls to query_qmake should fail hard if there no executable.

A regression due to 8ac7abb78d97210c5cbbc87fba83d58d7b843a8d Seems the "it allows for modules using it to decide what they should do" was never told the modules using it ;)

kossebau updated this revision to Diff 16912.Jul 19 2017, 2:03 PM
  • use cmake_parse_arguments
  • fix english grammar in dox
kossebau marked an inline comment as done.Jul 27 2017, 2:22 PM

If there are no objections, will push on Saturday, 29th July

apol accepted this revision.Jul 27 2017, 3:31 PM

Works for me.
Are you sure we don't need to include the TRY on other calls?

This revision is now accepted and ready to land.Jul 27 2017, 3:31 PM
In D6772#129531, @apol wrote:

Works for me.
Are you sure we don't need to include the TRY on other calls?

Any calls you would be thinking off? The ones where this patch does not add TRY are in code which expects qmake to exist and the method to return a proper value, and which do not have a fallback plan if it doesn't. Which boils down to the case where the user explicitly set KDE_INSTALL_USE_QT_SYS_PATHS to TRUE but no qmake-qt5 is around.

These are the calls I am aware off, and where TRY is only passed if failing is handled directly or rather indirectly):
kde-modules/KDEInstallDirs.cmake: query_qmake(qt_install_prefix_dir QT_INSTALL_PREFIX TRY)
kde-modules/KDEInstallDirs.cmake: query_qmake(qt_plugins_dir QT_INSTALL_PLUGINS)
kde-modules/KDEInstallDirs.cmake: query_qmake(qt_imports_dir QT_INSTALL_IMPORTS)
kde-modules/KDEInstallDirs.cmake: query_qmake(qt_qml_dir QT_INSTALL_QML)
kde-modules/KDEInstallDirs.cmake: query_qmake(qt_docs_dir QT_INSTALL_DOCS)
modules/ECMAddQch.cmake: query_qmake(qt_docs_dir QT_INSTALL_DOCS TRY)
modules/ECMGeneratePriFile.cmake: query_qmake(qt_install_prefix_dir QT_INSTALL_PREFIX TRY)
modules/ECMGeneratePriFile.cmake: query_qmake(qt_host_data_dir QT_HOST_DATA)

This revision was automatically updated to reflect the committed changes.