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

[Thiago Macieira]

On Sunday 18 January 2015 06:56:28 Kevin Kofler wrote:
> The issues are:
> * conceptual: Choosing a Qt version ought to be:
>   - the job of the software being built (i.e., its build system(*)), whose
>     developer knows what version of Qt is needed, not the job of the user
>     building the software. This is a fundamental conceptual disagreement.
>     The goal of our setup has always been that the user should NOT have to
>     do anything other than (e.g.) cmake . ; make ; make install to build
>     software, and the software should select its Qt by itself,
>   - a setting specific to the program being built and not to the user
>     account or even the shell environment.

If we're talking about qmake as the buildsystem, the above simply doesn't make 
sense for qmake, since it compiles for one Qt version only and, therefore, 
whoever is building the package needs to know which qmake to invoke.

If it's something else, how said software declares which version of Qt it 
wants is its own business.

We only need to discuss how to *find* that Qt version.

1) if a distro ships Qt 3, let qmake be Qt 3's
2) if a distro ships both Qt 3 and Qt 4, let Qt 4's qmake be qmake-qt4
	This is a historical mistake but now is legacy
3) if a distro ships Qt 4 but not Qt 3, then qmake is Qt 4's
4) if a distro ships Qt 5, then qmake is qtchooser and the default.conf is 
   ruled by 1-3 above

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.

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"

Option C: Qt 5 software doesn't bother trying to run qmake and simply assumes 
the tools are in $PATH.

> * practical: How do you propose that, say, an autotools setup (let's skip
>   CMake, where the *Config.cmake files are doing wonders) checks whether
>   "moc -qt5" will work as advertised? (It could get any old "moc" binary
>   without a qtchooser wrapper.) With the suffixed binary, a simple
>   AC_CHECK_TOOL (check whether moc-qt5 exists in the PATH) does the job. (If
> you go the "run qmake, use it to get the path to the unwrapped/unsuffixed
> moc" road, same question with "qmake -qt5" vs. "qmake-qt5".) The same goes
> for pretty much ANY build system out there.

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.

In any case, let's analyse the situation: software that chose options A or B 
above will have got the full binary path from either qmake or from qtchooser. 
So they can simply run $(bindir)/moc and be confident it works. There needs to 
be no additional check. 

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.

I would personally choose either A or B, depending on whether I also want to 
check the Qt version. qmake can tell me the Qt version but qtchooser can't.

> And by the way, even the conceptual thing is also quite practical. I have
> all of qt3-devel, qt(4)-devel and qt5-*-devel installed, and I can build
> programs with all three versions without having to reconfigure my system in
> any way.

I don't see why my solution would force you to reconfigure anything.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center