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

[Thiago Macieira]

On Sunday 18 January 2015 01:05:50 Kevin Kofler wrote:
> 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.

At that point, we had then two choices: assume we wouldn't ever agree and 
leave it at that, or find a compromise.

The compromise was to "rename" with and added space. So instead of 
	qmake-qt5

it is

	qmake -qt5

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

I personally preferred to rename them. 

Either way, the majority opinion won. People had scripts that shouldn't have 
to be updated, as Qt 5 is mostly source compatible. That extended to the 
buildsystem too: keep it compatible.

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

How is:

	configure --with-qt4
	configure --with-qt5

That much different from

	qmake -qt4
	qmake -qt5

?

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

For the simple reason that the only OS not under that list is Windows. On 
Windows, qmake is *never* in the system default PATH. Windows developers were 
already used to changing PATH and/or typing full paths. In fact, Windows 
developers simply launch the "vars" batch file that sets the environment 
correctly for the compiler they want to use.

qtchooser can be made to work on Windows. No one has bothered because there 
has just been no request to.

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

Indeed, we wouldn't change Qt3's qmake. But that's not much different from 
running a configure script for a Qt3-based application, which gets the version 
and concludes "5 > 3, good!" and then proceeds to a build failure.

Also, we agreed that the number of Qt 3 applications still in the wild is 
pretty small: those that still need them know them pretty well. That's also 
why the default unsuffixed "qmake" should be Qt 4's.

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

You're talking about a buildsystem that runs qmake? I was thinking of the 
buildsystem being qmake itself, in which case the task of running qmake falls 
on the packaging system (your .spec file).

Like I said, the decision was made this way:
 1) Qt 3 was considered irrelevant at the time
 2) any buildsystems that already existed at the time would, by exclusion, be 
    about Qt 4. Therefore, the default "qmake" should be Qt 4's.
 3) any new applications for Qt 5 or new buildsystems would know about the 
   rule and would use "qmake -qt5"

And here we must split the blame: I never got to write the page that explained 
what packagers should do. I worked with Sune for Debian (who was apparently 
the only packager interested) and I ended up forgetting about the page. But 
other distros never engaged me, insisted on the instructions, and instead just 
did whatever they wanted. So buildsystems can't rely on the solution we came 
up with because distros just went whichever way they wanted, without caring 
for the poor buildsystem writers...

> And what is the benefit of running "qmake -qt5" over "qmake-qt5"? All it
> does is add one space.

Because it also works for those of us who have multiple Qt 5 builds. I can 
run:
	qmake -qt5
	qmake -qt5-release
	qmake -qt5-icc
	qmake -qt5-clang
	qmake -qt5-mips
	qmake -qt5-static
	qmake -qt5.1

What's more, by setting QT_SELECT, I can change the default, without having to 
fiddle with PATH.

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

I'll grant you the "you could be running Qt 3". That is indeed an issue.

I will not grant you "you have to run". Just run it and check if it failed to 
run. It's like checking for a file's existence before opening it: just open it.

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

How?

You can keep the default as is, so no one will know that the default qmake is 
now qtchooser. But you will support the standardised way.

And if you're not willing to reconsider, then we can end the discussion here 
and declare Fedora unsupported.

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

Again, we discussed this prior to 5.0. There was a consensus of all 
distributions who bothered to discuss the issue.

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