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

[Kevin Kofler]

Thiago Macieira wrote:
> 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).

Yes, I'm talking about a non-qmake build system that builds Qt stuff, that 
has to do one of:
a) invoke qmake* to find the Qt directory, then invoke e.g.
   $THE_QT_DIR/bin/moc (how FindQt4.cmake does things),
b) invoke things like moc-qt5 directly,
c) shell out to qmake* and make to build the Qt parts.
In all 3 cases, the build system needs to know about the suffixed binaries 
resp. the qtchooser wrappers: In case a and c, it needs to use qmake-qt5. In 
case b, it needs to use moc-qt5 etc. (Add a space for the qtchooser case.)

Hint: Most programs out there (even Qt programs) do NOT use qmake as their 
build system. For those that do, the user indeed needs to run the right 
qmake either way. (There's no good solution for that then, unless you wrap 
it with a shell script. Some projects ship a "configure" script that runs 
qmake. In fact, Qt itself actually does that too.) There, it doesn't indeed 
make a real difference whether he/she has to run "qmake-qt5" or
"qmake -qt5". The good news, though, is that those are the projects that 
also definitely just work with our suffixed binaries without the project's 
upstream having to do anything. (Sure, qmake does not support suffixed uic, 
moc, etc., but it knows the directory where the correct unsuffixed versions 
are and runs them from there, which also works fine. Qt 5 projects using 
CMake just work with our setup for the same reason.)

> 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

Well, you could install all those as suffixed versions without the space, or 
just run them from their specific bin directories.

And to be honest, this is not really a use case we care about in 
distributions (at least not in Fedora):
* We do not ship separate debug and release builds of Qt (or any other
  package, except the kernel). We build everything in "release with
  debugging information", and RPM automatically splits the debugging
  information into a separate -debuginfo package (that also contains the
  referenced source files).
* We do not ship builds compiled with different compilers. All C/C++
  programs in Fedora are built using GCC, except those that ONLY build with
  e.g. Clang (and ICC is not even in Fedora to begin with, because it is not
  Free Software). It shall also be noted that both ICC and Clang are binary-
  compatible with GCC for C and C++ on GNU/Linux and thus should not
  actually require a separate build of Qt (though I haven't verified that).
* For cross-compiling, the long-established standard is to name the
  executables $targettriplet-foo, e.g., mips-unknown-linux-gnu-qmake-qt5.
  Build systems need to know about this convention anyway if they want to
  successfully cross-compile, because the toolchain also uses that naming
  convention. This is, e.g., how our mingw32-qt5-qmake is packaged (it ships
  /usr/bin/mingw32-qmake-qt5, /usr/bin/i686-w64-mingw32-qmake-qt5 and
  /usr/i686-w64-mingw32/bin/qt5/qmake). (It does also ship an
  /etc/xdg/qtchooser/mingw32-qt5.conf for those who want to use qtchooser.)
* We do not ship a static build of Qt. Shipping static libraries is actually
  discouraged in Fedora and most libraries are configured with
  --disable-static.
* We ship one version of Qt n for any given major version n. In Fedora,
  that's normally the latest, which is backwards-compatible with (almost)
  all programs written for the older versions. (There were issues with some
  KF5 packages using private APIs, but a straightforward rebuild solves that
  problem.) If a new version comes out, we just push it as an update. Why
  would we want to ship Qt 5.1 when 5.4 is current?

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

So you set one environment variable instead of another? Was that really 
worth the effort of writing those wrappers?

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

All Qt 3 programs will break.

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

Why won't you consider the solution I proposed? (Ship both qmake, uic, moc 
etc. AND qmake-qt5, uic-qt5, moc-qt5 etc. in Qt 5.5, document the former as 
deprecated in favor of the latter, also deprecate qtchooser. Eventually drop 
the unsuffixed versions in Qt 6.0, shipping only -qt6 ones. The result would 
be that programs still using Qt up to 4 would be no worse off than they are 
right now, programs using Qt 5 would be able to migrate to the now 
officially supported suffixed binaries (and if they don't, they would be no 
worse off than they are right now either), and for Qt 6 and later, the issue 
would be resolved once and for all, there would be one standard binary name 
to invoke: the suffixed one.)

        Kevin Kofler