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

[Thiago Macieira]

On Sunday 18 January 2015 23:13:30 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > This, Qt 3 software do "qmake". Qt 4 software do "qmake -v" to determine
> > which version it is: if they found Qt 3, they try "qmake-qt4". All of this
> > is already implemented and was in place before 2012.
> 
> Why would they need to try running anything? Just use qmake-qt4 if it
> exists, and qmake otherwise. The same works with our qmake-qt5.

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.

> > As for Qt 5 software, they have three choices:
> > 
> > Option A: Qt 5 software do "qmake -qt5" and the result is one of two
> > 
> > options:
> >  1) qmake is qtchooser, so it works
> >  2) qmake is not qtchooser, so it will return an error, in which case they
> >  can conclude Qt 5 is not installed
> > 
> > Option B: Qt 5 software do: "qtchooser -qt5 -print-env" and parse the
> > result. Here it is:
> > QT_SELECT="5"
> > QTTOOLDIR="/home/thiago/obj/qt/qt5/qtbase/bin"
> > QTLIBDIR="/home/thiago/obj/qt/qt5/qtbase/lib"
> 
> This means they need to actually run the executables, whereas with the
> suffixed binaries, they need to check for their existence. And in practice,
> portable programs also need to check for qmake-qt5 ANYWAY because it is
> already in widespread use (at least Fedora, RHEL, CentOS, Scientific Linux,
> etc., maybe also others, I haven't checked lately what other distributions
> ship), and there is no way this is going to change in the 10 years of life
> time of RHEL 7.

I'm ignoring qmake-qt5 because it's totally non-standard. You guys created the 
problem, you guys can pick up the pieces. If buildsystems don't work with your 
modifications, it's your problem, not ours. We had a solution you chose not to 
adopt.

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

> > Option C: Qt 5 software doesn't bother trying to run qmake and simply
> > assumes the tools are in $PATH.
> 
> Those programs are what I call "broken" and curse at whenever I see them
> (and then submit a patch checking for qmake-qt5 to; most upstreams other
> than you (Qt Project) are receptive to such patches).

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

> > Is this autotools-based setup a unit test for moc? No? Then why is it
> > trying to verify that it works as advertised? How can you tell what is
> > "works as advertised"?
> > 
> > The only way to verify that it works is to actually run it and compile the
> > result against the qobjectdefs.h header. If there's a mismatch, it will
> > either fail to compile or link. Other than that, there's nothing you can
> > do to verify that it works as advertised.
> 
> If the binary is called "moc-qt5", it is safe to assume that it is a moc
> from Qt 5. If the binary is called just "moc", there is indeed no telling
> whether it will accept a "-qt5" argument without trying to run it with that
> argument. That was my whole point.

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.

> > Software that chose option C runs "moc -qt5" and, just like option A for
> > 
> > qmake, it will:
> >  1) moc is qtchooser, so it works
> >  2) moc is not qtchooser, so it will stop with an error, in which case you
> >  can conclude there's no Qt 5 installed.
> 
> And that conclusion will be wrong on any system that does NOT use qtchooser.

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

> There will always be systems with Qt 5 and without qtchooser (even if
> Fedora and RHEL were to adopt it, which is extremely unlikely to happen
> too, especially for existing RHEL releases). Qtchooser is not even part of
> Qt, so people building Qt from source will by default end up without it.
> And distributions shipping only Qt 5 will also likely not want to bother
> with qtchooser. If PATH was explicitly set to /usr/lib64/qt5/bin:$PATH or
> if the Qt 5 binaries are symlinked directly into /usr/bin, moc is not
> qtchooser, but running it without the "-qt5" flag would work.

We can easily add it to Qt if that's the problem.

And like I said, Fedora's and RHEL's refusal to follow the recommendation is 
their own problem. You get to pick the pieces from what you broke.

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