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

[Kevin Kofler]

Thiago Macieira wrote:
> Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't
> renamed. Software is supposed to work with the official version too and
> there are 9 years of history of us releasing "qmake".
> 
> Therefore, that buildsystem needs to try qmake alone.

The point is, try qmake-qt4 first, and if it doesn't exist, try just qmake. 
That will work in all cases, and does not need test-running anything, only 
checking existence.

> I'm ignoring qmake-qt5 because it's totally non-standard.

It is only "non-standard" because you (Qt upstream) refused to settle on the 
convention almost every distribution in the world has been successfully 
using for years (for Qt 4). (I know that at least Fedora, RHEL and 
derivatives, Debian and Mandriva used -qt4 suffixes at some point. There 
were probably several more. Some of them, like Debian, dropped the suffixes 
as a result of dropping Qt 3.) So YOU created the mess where we now have 2 
competing approaches. We only decided to stick to the standard that has 
worked for years.

I'll also point out that it would be possible in principle to support BOTH 
suffixed binaries and qtchooser (in fact, that's what happens if one 
installs the optional qtchooser Fedora package), but the many practical 
issues with qtchooser (that I have pointed out elsewhere in this thread) 
make us not default to such a setup.

> But yes, they need to run things. How is that different from running
> pkg-config? Or running mysql_config?

That is not a "try to run something and catch the error" approach. Approach 
which also assumes that you get an error to begin with, and the unhandled 
argument is not silently misinterpreted as meaning something completely 
different.

> In other words, instead of fixing what you broke in one place, you send
> workarounds to everyone else (N places).

s/workarounds/fixes/

I'll also point out that most stuff that does not check for suffixed 
binaries also does not support qtchooser either.

> That check is irrelevant.
> 
> You either run a full path to moc, which you obtained from qtchooser or
> qmake, or you run "moc -qt5". Any of those three are going to successfully
> run the Qt 5 moc if it's there or it's going to fail.

The tool can always be in the default path.

> Which should be zero. All systems should use qtchooser, except Windows.

Yet even the tool's own documentation explicitly claims that it is also not 
for OS X.

And at this point, we really cannot expect qtchooser to "catch on" anymore. 
It is always going to be an obscure hack that only some Qt developers and 
Debian are using. It is time for you to admit that it was a failure, and 
finally ditch it.

Qtchooser blatantly violates the "KISS" principle. (It is completely 
overengineered.) It also introduces some very nondeterministic behavior, 
such as invoking one and the same executable ending up running a completely 
different binary depending on the contents of a configuration file (!) or an 
envionment variable (!). There is a very simple solution to the problem of 
coexistence of multiple Qt versions: the -qt5 suffix. Your qtchooser wrapper 
is much more complicated and thus much harder to maintain. (Even with our 
only optional support for qtchooser, we ran into several packaging issues 
caused by it. The multilib issue I mentioned was one of them.)

> And like I said, Fedora's and RHEL's refusal to follow the recommendation
> is their own problem.

It is also going to be your problem if programs get written for Fedora 
and/or RHEL and thus hardcode qmake-qt5 (which in fact I may well actually 
start RECOMMENDING to developers, to force both other distros and upstream 
to start supporting it). Welcome to the real world!

        Kevin Kofler