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

[Kevin Kofler]

Thiago Macieira wrote:
> The one requirement that came from the Qt Project was that the tools would
> not be renamed.

And the one requirement that came from the distros was that the tools must 
be renamed. This was made very clear from the beginning. All other solutions 
are and will always be inherently flawed.

You also never gave any convincing argument as to why you refused to rename 
the binaries.

> On a system where Qt 4 will never be installed, "qmake" with no arguments
> can be Qt 5's qmake. Otherwise, it's Qt 4's.

On Fedora with the default PATH, unsuffixed "qmake" is actually Qt 3's. 
Programs that assume that "qmake" is Qt 4 have never built on Fedora without 
messing with PATH. (They should run "qmake-qt4", which is/was also required 
on several other distributions, at least when they still shipped Qt 3.)

> The instructions were done this way because there are many applications
> that compile with both Qt 4 and Qt 5. So the choice of which one to use is
> left to the builder. It's no different from many other applications and
> libraries coming from KDE, which for a time offered support for both Qt 4
> and Qt 5. With the difference, of course, that you had to find out for
> each one which -D option to cmake would turn it this way or that, instead
> of a common solution for all.

The -D flag (or equivalent in other build systems, e.g., --with-qt5 in 
autoconf) is what basically all the upstreams in this situation implemented 
anyway (all those that didn't just ignore the problem and falsely assume 
that "qmake" is the Qt version the code happens to be coded for and/or the 
one the user happens to want to use), not just KDE.

This is a per-program setting (in fact, those that support both are often 
libraries, where one actually wants to build them twice, once for Qt 4 and 
once for Qt 5), not a per-user setting that can be put into a user-account-
wide configuration file.

> Which you shall never install globally.

But things are different on other operating systems. Qtchooser is explicitly 
documented (by you) as being only for GNU/Linux or POSIX systems. Programs' 
build systems often need to work on more than that.

> That's why qtchooser is the only recommended installation for "qmake". If
> the problem is the argument, we can fix qmake to ignore a first argument
> starting with "-qt" and simply print a warning that it was ignored.

That might alleviate the problem somehow, but the build system could still 
end up running the wrong qmake somehow. (And also, I strongly doubt that you 
want to implement this in the Qt 3 qmake which is the default unsuffixed 
"qmake" here. You also cannot go back in time to fix the qmakes of all the 
existing Qt releases.)

>> 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.
> 
> I don't see how you wouldn't know what you chose for your distribution.

We know it. The upstream project for the client program using Qt doesn't 
(because it's distro-specific), and to get this right in their build system, 
they need to know. (That said, if you say just "5" is the standard, at least 
that particular objection does not apply. But then it should be documented 
in qtchooser; last I checked, it wasn't.)

> Except where they don't. They're non-standard. Renaming of the binaries is
> not supported and we may break them, accidentally. Don't rename. We've
> been saying this for almost 10 years now.

This just shows how you do NOT care about how Qt is packaged in real-world 
distributions. The goal should be to support existing de-facto standards 
instead of trying to tell us all that we're all doing it wrong (when there 
are good reasons to do things the way we do).

The only issue I see with the suffixed binaries is that some programs' build 
systems fail to check for them. Supporting them officially in upstream Qt 
would help getting that fixed.

>> 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).
> 
> Which they wouldn't have to if it were standardised to run "qmake -qt5".

And what is the benefit of running "qmake -qt5" over "qmake-qt5"? All it 
does is add one space. And the big drawback for a build system is that you 
need to actually invoke "qmake -qt5" to check that it works (for all you 
know, you could be running Qt 3 qmake, or getting a "command not found" – in 
fact, one or the other is going to happen on Fedora and RHEL depending on 
whether qt3-devel is installed or not – your new standard will not magically 
fix older distributions), whereas with the "qmake-qt5" approach, you can 
check for the binary's existence in the PATH (a one-line command/macro in 
any sane build system).

As far as I can tell, the practical build system support for your purported 
"standardized" way is also actually lower than support for the suffixed 
binaries.

> Please reconsider. There's something to gain just by being compliant with
> what we standardised and recommend.

This will never be reconsidered. It would break backwards compatibility with 
our existing releases.

> Will not happen for Qt 5. Simply can't. If you have a time travel machine,
> go back to 2011 and convince people that this was acceptable. Renaming the
> binaries was the one thing that the majority of Qt developers did not
> want.

See, you have compatibility concerns? Well, we do, too.

And supporting suffixed binaries in upstream Qt is actually very easy: You 
ship both, you make the binaries print a deprecation warning if argv[0] does 
not include the suffix, and you document *-qt5 as the new official way to 
invoke the binaries. Then distributions decide what to do with that 
(symlink/hardlink the suffixed binaries to /usr/bin, symlink/hardlink both 
suffixed and unsuffixed binaries, set PATH, or whatever).

And when you ever get to Qt 6, you ship only *-qt6 binaries and drop the 
unsuffixed binaries completely. (For the lifetime of Qt 5, you'll have to 
keep them as deprecated, I'll concede that point.)

> So, yes, qtchooser is the next best thing. But you're refusing to adhere
> to the common way. Fair enough, I'll just recommend anyone using Fedora
> packages in #qt to go to #fedora, since you're refusing to standardise...

You are the ones refusing to adhere to the common way that distributions 
have been shipping Qt for years.

        Kevin Kofler