When running eqmake5 on a project (ktikz, only in my overlay, see https://gitweb.gentoo.org/dev/dev-zero.git/tree/media-gfx/ktikz/ktikz-9999.ebuild?id=eb399ae40038ff9980e82729f17d96da995534a2) which calls `qcollectiongenerator` somewhere during the build process, I get the following failure: qcollectiongenerator: could not exec '/usr/lib64/qt4/bin/qcollectiongenerator': No such file or directory For some reason, qtchooser selects Qt4 at some point. This can be avoided by adding `export QT_SELECT=5` before the `eqmake5` call.
We can't really export QT_SELECT from the eclass, it wouldn't work for ebuilds supporting multiple Qt versions. Besides, it would be a workaround for a broken build system. We've seen surprisingly few broken build systems wrt the Qt4 vs. Qt5 transition, so I'm not interested in adding workarounds to the eclass. So either keep the QT_SELECT workaround in the ebuild, or use qt5_get_bindir(), or even better, tell upstream to fix their build system. They should use something like `$$[QT_INSTALL_BINS]/qcollectiongenerator` instead of simply `qcollectiongenerator`.
You can pass QCOLLECTIONGENERATORCOMMAND="$(qt5_get_bindir)"/qcollectiongenerator to eqmake5 to override the wrong unqualified binary used by default. LRELEASECOMMAND needs a similar fix. https://github.com/jfmcarreira/ktikz/blob/master/qmake/qtikzdefaults.pri#L3
(In reply to Davide Pesavento from comment #1) > So either keep the QT_SELECT workaround in the ebuild, or use > qt5_get_bindir(), or even better, tell upstream to fix their build system. > They should use something like `$$[QT_INSTALL_BINS]/qcollectiongenerator` > instead of simply `qcollectiongenerator`. I personally prefer the non-QT_SELECT solutions are they are more robust. Right now my qtchooer is horribly broken so none of the /usr/bin symlinks do anything (and as you've mentioned, there's surprisingly little breakage).
