Without any hint, qmlplugindump version is whatever default is set by qtchooser.
Details
- Reviewers
apol krop - Commits
- R240:92eb3e9767cb: Make sure to search for Qt5-based qmlplugindump
ecm_find_qmlmodule now works properly for e.g. kirigami.
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.
Well, it's just a hint. If it's not found there, no harm done. But yeah, at least the paths for most distros could be there, to be fair ;)
For OpenSuSE no change needed, it's in /usr/bin.
Which distro was this commit for? Looks like a debian/ubuntu path? If so, how did this go unnoticed until now?
it's a packaging issue if executables that don't have a .desktop file are not in PATH. An alternative could be to use qtpaths but it adds a dependency on qttools (and wouldn't help if it's installed in the same dir).
This is for Gentoo - now I don't do Qt packaging, but as far as I'm aware this is pretty vanilla.
The point of this change is that ECM should not rely on the default set by qtchooser/default.conf which can be either Qt4 or Qt5. qmlplugindump is not a binary that is exclusive to Qt5.
is this a problem caused by qmlplugindump being one of those magic things that are "symlinks" to the qt4 or qt5 depending on the QT_SELECT env var?
maybe makes more sense to fix the execute_process so that it sets QT_SELECT to 5?
ECM provides ECMQueryQmake.cmake. you can try eg:
include("${ECM_MODULE_DIR}/ECMQueryQmake.cmake")
then calling query_qmake(qt_binaries_dir QT_INSTALL_BINS)
and use ${qt_binaries_dir} as HINT