Currently if a qmake project gets invoked with eqmake5, qtchooser can fallback to Qt4 binaries, so that if Qt tool are invoked inside qmake, the Qt4 ones are picked, leading to compile or other errors in some projects and some combination of installed packages. As a workaround for that, one has to define src_compile() and export QT_SELECT, so that Qt5 tools are forced, which is kind of suboptimal, because with the invokation of qmake5 the author of the ebuild already stated, that he wants Qt5. A good idea would be to have a variable outside of the functions like QMAKE_QT_VERSION and inside the functions only eqmake has to be called (no eqmake4 or eqmake5), then qmake-utils can tell qtchooser which tools to use. Reproducible: Sometimes
(In reply to Karol Herbst from comment #0) > Currently if a qmake project gets invoked with eqmake5, qtchooser can > fallback to Qt4 binaries, so that if Qt tool are invoked inside qmake, the > Qt4 ones are picked, leading to compile or other errors in some projects and > some combination of installed packages. I'm not aware of this problem, can you cite some examples? (it should not happen if the build system is sane)
the problem is, I forgot under which circumstances the bugs appears, but it is likely, that the build system isn't that sane and calls the tools directly through system(tool ...). I've added someone with that problem in CC. I think the tool making problems was qdbusxml2cpp, of whom the Qt4 version got executed, which shouldn't happen any may also be the fault of the build system, but we can't simply assume every qmake project will do this right.
found it in IRC log: https://bpaste.net/show/e7b7e6ec6228 line 286: "qdbusxml2cpp: could not exec '/usr/lib64/qt4/bin/qdbusxml2cpp': No such file or directory"
so to sum this example up: if Qt4 version of qdbusxml2cpp is installed, the Qt4 version generates source and the project builds against it => wrong if the Qt4 version of qdbusxml2cpp is NOT installed, the compilation fails (even if the Qt5 version IS installed) => wrong
Yeah the package build system is broken, so what? I'm not interested in adding workarounds to the eclass for a small (so far) bunch of broken packages.
