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

[Thiago Macieira]

On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote:
> 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. 

It was designed in consultation with distros, for distros and for our current 
developers. Lots of people from the distros were present in the discussion 
when it started.

The one requirement that came from the Qt Project was that the tools would not 
be renamed.

> 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.

The instructions are simple:

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.

The official way of running Qt 5's qmake is:
	qmake -qt5

Which implies that the Qt 5 development files install a "5.conf" global 
configuration file. That's all.

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.

> 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, 

Which you shall never install globally. 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.

> 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.

I don't see how you wouldn't know what you chose for your distribution.

> 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.

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.

> 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".

> (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).

Again, many applications and libraries offer the choice. The difference is 
whether the option is standardised or not.

> 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.

Except for the standardised way.

> 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.

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

> 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.

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.

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...

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center