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

[Kevin Kofler]

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.

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

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

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

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

For the suffixed binary approach, the program just needs to use 
AC_CHECK_TOOL to check for moc-qt5, and (if it cares at all about older Qt 5 
builds before the introduction of suffixed binaries) if not found, 
AC_CHECK_TOOL for just moc. (Other build systems have similar macros. CMake 
has the FIND_PROGRAM command, but for CMake, you ship the *Config.cmake 
files that just work anyway. Checking the existence of a given executable in 
the PATH is a common basic operation in build systems.) Much simpler.

> I don't see why my solution would force you to reconfigure anything.

Because many build systems out there in practice do not support qtchooser 
(other than by having the user change the default Qt manually), and it is 
not straightforward to support it. On the other hand, supporting the 
suffixed binary setup is straightforward.

        Kevin Kofler