[Development] Build system for Qt 6

[Kevin Kofler]

Ray Donnelly wrote (NOTE: I reordered the quotes so that my replies can be 
read in order):
> I work in the Anaconda Distribution as a software packager and spend a
> significant amount of my working day battling cmake. As I say it's "ok"
> for developers but not for packagers.

I'm a packager for Fedora, a GNU/Linux distribution. I find CMake to be the 
nicest build system to work with. It is common enough for there to be macros 
and snippets/templates making it easy to package software using it.

The same theoretically applies to the Autotools, but the Autotools are a 
pain as soon as you need to change something, because:
* the script that is executed is generated, so if you make any changes to
  the actual source code, you have to rerun autoreconf or equivalent, and
* the syntax is harder to work with, so it is harder to make changes to
  begin with.
CMake, on the other hand, only requires you to edit the CMakeLists.txt 
file(s), with a much nicer syntax.

In addition, if we fix a bug in the autotools themselves, or in some aclocal 
snippet, we also have to regenerate or patch the generated files in dozens 
of packages bundling the generated scripts. On the other hand, if we fix a 
bug in CMake or in a Find*.cmake/*Config.cmake installed systemwide, a 
rebuild with no changes is enough to get other packages to pick up the fix.

Custom build systems only used by one or a handful project(s), such as QBS, 
GN, etc. are a pain because they require custom build instructions in our 
package specfiles that are specific to that build system (e.g., whereas 
Autotools and CMake use DESTDIR, QMake insists on INSTALL_ROOT) and because 
there are often no templates for those custom instructions (because your 
package's specfile likely *is* the template).

(Sadly, I don't think we will ever be able to build QtWebEngine without GN 
or yet another Chromium-only replacement (GN was already the replacement for 
Gyp). Chromium insists on using custom non-standard tooling.)

And then there are the build systems that are a *real* pain, e.g., those 
that try to automatically download dependencies from the Internet (a no-go 
during our package builds). The only way to get dependencies downloaded is 
*before* the build starts and only from Fedora packages (not some random web 
location), by specifying them as BuildRequires in the specfile. The build 
system must *never* attempt to download anything. As I understand it, Bazel 
is one of the major offenders there.

> I'll not going to do this for you, sorry. I also pointed out the lack of
> isolation from system libraries by default as a major problem.

Here in Fedora, we actually *want* CMake to find system libraries. The 
situation on Windows is of course different, and third-party packages for 
GNU/Linux may or may not want to use the system libraries, but our 
distribution packages definitely want to use them.

        Kevin Kofler