[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Kevin Kofler]

Thiago Macieira wrote:
> packagers, like we did in the past for qtchooser (a solution designed for
> distro's needs).

Hahaha, that's a good one!

Qtchooser is designed completely PAST distros' needs and entirely useless 
for distros. What we actually asked for (and have always been shipping, and 
at least in Fedora, still ship for Qt 5) is suffixed binaries. What you 
delivered instead is wrappers that move the onus on deciding which Qt 
version to use from the package/tarball's build system (which is surely the 
best place to know which major version it needs) to the user, using a per-
user-account configuration file.

Sure, it is also possible to select the Qt version with a command-line 
argument to the qtchooser wrappers, but since the binary with the exact same 
name could also be an unwrapped binary, which does NOT handle that command-
line argument, it is impossible to reliably use those command-line arguments 
in build systems. The third method, magic environment variables, is also not 
very suitable for some build systems. In addition, both the command-line and 
the environment variable methods share the problem that the names of the 
available Qt versions are not standardized (e.g., do they include only the 
one-digit major version number? the 5.x major-minor version number? the full 
5.x.y version number? with or without arch suffix? etc.), making them 
unsuitable for build systems to use.

On the other hand, the suffixed binaries, with the de-facto-standard naming 
convention (*-qtN, where N is the major version) that distros have been 
using for years, just work. Build systems only have to check for qmake-qt5 
first and then fall back to qmake (and the well-designed build systems in 
fact already do that). (As for CMake, your shipped *Config files for Qt 5 
actually find the unsuffixed binaries directly in the non-PATH directory and 
thus also do not need qtchooser. For Qt 4, see "well-designed build systems" 
above, FindQt4.cmake gets it right.) The user does not have to pick a Qt 
version, the software he/she is trying to build (which KNOWS what version of 
Qt it wants) picks the binaries with the correct suffix automatically (and 
if not, that software's build system is broken – mostly only an issue with 
stuff coming from Qt upstream, which assumes that everyone ships Qt exactly 
as upstream and ignores real-world distribution packaging entirely).

It shall also be noted that even if one accepts the idea that the user 
should select a Qt version to use, that can be implemented without any 
wrappers such as qtchooser, by simply prepending the relevant bin directory 
to the PATH. (This is also the workaround we use in specfiles for broken 
build systems that do not understand suffixed binaries.) In other words, 
qtchooser does not provide any value at all to our users.

Therefore, we are NOT shipping qtchooser in Fedora by default, and our 
qtchooser package in the online repository (package which we only ship at 
all due to the insistence of one individual packager – both I and the 
primary maintainer of Qt in Fedora have requested its removal from Fedora 
more than once) does NOT automatically add itself to the PATH.

So, sorry, but qtchooser is exactly an example of how NOT to do things. I 
can only urge you to finally implement our original request of just 
officially adding the required -qt5 suffix to all the binaries, and to 
deprecate or outright drop qtchooser.

        Kevin Kofler