Passing NO_DEFAULT_PATH ignores $PATH and ensures that we use the
previously-detected Qt5 binary path.
Details
Details
- Reviewers
kossebau kfunk - Group Reviewers
Frameworks - Commits
- R240:a13f1dcd2e7b: FindQHelpGenerator: avoid picking up Qt4 version
qhelpgenerator is now picked up from the same location as Qt5::qmake. Before,
anything in $PATH was preferred even if it was the Qt 4 version.
Diff Detail
Diff Detail
- Repository
- R240 Extra CMake Modules
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
Thanks for the fix. Sadly this fails on my openSUSE TW system with system Qt5 packages, where _path is /usr/lib64/qt5/bin, and while that dir has both qhelpgenerator-qt5 and qhelpgenerator files, they are links pointing to the actual executable file located at /usr/bin/qhelpgenerator-qt5
lrwxrwxrwx 1 root root 31 28. Mai 12:40 /usr/lib64/qt5/bin/qhelpgenerator-qt5 -> ../../../bin/qhelpgenerator-qt5 lrwxrwxrwx 1 root root 31 28. Mai 12:40 /usr/lib64/qt5/bin/qhelpgenerator -> ../../../bin/qhelpgenerator-qt5
Still had no time to investigate some more why this fails.
(Actually it is not such an issue if the Qt4 version is used, it's working as well. But still using the latest version of qhelpgenerator, as provided by qt5, feels better -> "newer is better!")
Comment Actions
Ah, PEBKAC, I only added NO_DEFAULT_PATH to the code when manually applying the patch. Fixing also PATH->PATHS improved things, and the executable now is found in ${_path}.
No more objection from my side :)
Comment Actions
@palimaka You have KDE push rights, correct? Will you have time this week to push this, or do you want someone/me to do that for you?
Would be good to have this in as soon as possible, given tagging release is <2 weeks away :)