[Development] Proposing CMake as build tool for Qt 6

[Kevin Kofler]

Lars Knoll wrote:
> That thread doesn’t explain why qtchooser isn’t a solution. It does work
> without problems for all my use cases, and I certainly do have quite a few
> Qt versions installed in parallel.

There are 4 crucial design flaws that make qtchooser unsuitable for 
distributions:
1. The choice of preferred Qt version is a user configuration. It should be
   a configuration set by the build system of the program being built. The
   program should know what Qt version(s) it supports. I should not have to
   configure the version to use before I compile something. This can be
   worked around by explicitly passing the -qt option in the build system,
   but that leads us to:
2. The build system has no portable way to know whether the binaries it is
   about to run are wrapped by qtchooser or raw binaries. If it tries
   passing qtchooser options to the raw binaries, it will likely get an
   error (and catching that error is the only way to know for sure). Even if
   the raw binaries get "fixed" to ignore qtchooser options, that will not
   solve the issue for all the old raw binaries around. (If you call
   unsuffixed binaries on Fedora, you will likely get Qt 3 ones.)
3. The names or numbers that can be used with -qt are not standardized.
   Something like -qt5 will likely work in almost all qtchooser setups.
   Something like -qt5.12 or -qt5_64bit may or may not work. This also
   limits the usefulness for automatic use in build systems or scripts.
4. The build system has to actually run the qtchooser wrappers to know what
   Qt version(s) is/are installed (and then try to actually understand the
   returned list, see point 3 above), not just check for file existence.

In contrast, with suffixed binaries (e.g., qmake-qt5):
1. The build system decides whether to run qmake-qt5 or qmake-qt6 (and those
   should always be tried BEFORE unsuffixed qmake, which is likely the
   oldest version that the distro still supports and can be as old as Qt 3!
   Ideally, Qt upstream would finally standardize on suffixing for Qt 6 and
   so unsuffixed qmake wouldn't have to be tried at all anymore).
2. The build system always gets to run the real binaries (and does not have
   to rely on wrapper options to get the correct binary).
3. The suffix should be standardized by the upstream installation (i.e.,
   make install should install the tools with that suffix). The de facto
   standard suffixes of the form "-qt5" (used in several distributions)
   should be adopted. If ABI breaks in minor releases are needed (which I
   still think is a horrible idea), then the suffix needs to be changed to
   something like "-qt6.3", e.g., "qmake-qt6.3".
4. The build system only has to check whether qmake-qt6 exists to know
   whether Qt 6 is installed, it does not have to actually run anything.

So the suffixed binaries are the far superior approach.

        Kevin Kofler