[Development] Qt 6 buildsystem support requirements

[Jason Newton]

I think this is an incredibly important issue!  Sorry if this creates
a new thread, I'm hopping on the ML and I don't have any previous
mails to reply-to.

I wanted to mention that this is on my mind alot for a few years days
as a user for a plethora of libraries.  My conclusion for the build
system with the brightest future is bazel and here's a few words why.
But first, let me direct to a ticket I filed last year on the subject
of Qt creator support of bazel:
https://bugreports.qt.io/browse/QTCREATORBUG-19085 - I really wish it
was something more trivial to integrate.

There are too many options right now and seeming none of them are
clear winners across the board, though several have shiny features
that as a former cmake purist, made me wish I had some of those
things.  I'd most be interested in meson if I chose to have a limited
scope and cmake wins out on "most" libraries supported, which seems to
have taken 5-7 years in my own experience for that shift to happen -
meaning an official or community based FindLibrary script being
available.  Cmake has verbosity and limitations though so while it
works, and is much better than a make based solution, when it comes to
jumping out 95% builtin coverage, particularly where it tends to go
more programming language/composition it has problems.  I'd support
cmake library users, but I wouldn't put the lion share of my effort in
it.  Meson has deterministic builds and a clean language but I can get
that with bazel too - I essentially look at both of these projects as
a very common set of features, but bazel features and capabilities
keep growing where as I'm not sure where meson will go.  Both meson
and bazel suffer from few out of the box, batteries included modules
for software libraries, leaving users to scrape github (like cmake in
its earlier years of mass adoption) - this is a problem that will go
away one way or another in time, and an official repo or library with
mass collection of them as well as upstream project support for more
non-trivial libraries (qt is one of these!) would go miles.

Why the qt project may be interested in this in short is:
-Probably the most unbounded future of any existing build system,
development is quite active with a growing feature set - this is not a
simple community effort but fused (although mainly driven by google)
and I think that's why you can count on this remaining true and ahead
of the pack.
-Time tested, running in production environments offering the lowest
barrier of entry to "get going" for bazel based projects being built
by users, even for non-programmer types.  As usual YMMV but I can
start a non-software person on a bazel project in a matter of minutes
and have a large project functioning on a machine - stories exist like
this from google and the like.
-Short, python based syntax but much less complicated files than
something like scons, while still allowing real programming when
needed.
-Fast and scaling bazel uses a long lived server technique that hangs
around and lower restart times and combined with solid dependency
analysis and a built in watching for file-system activity (e.g.
inotify) ensures smart rebuilding as well as incremental builds - even
as part of the test runner, which has access to this information such
that only what might have changed is tested. Large projects like qt
build incredibly fast and efficiently - through a variety of
strategies bazel takes.  Local build caches, external cache servers -
can greatly speed up CI based testing (meaning developers wait less)
and are integrated in a vastly superior way in contrast to say distcc.
The amount of time that useful work is being performed is  greater
than I've observed in large cmake projects, even using ninja (assuming
ninja would work across projects that size, due to frequent make
sensitivities)
-Ability to build external libraries from source or pull in binary
libraries - the former offering alot of power that comes with custom
flags and controlled dependencies for users developing products, and
the later for distribution like software - the choice is always there
and low barrier of entry.  One can fuse approaches where it makes
sense.
-Cross-platform builds work, esoteric stuff does too - docker, android
and specialized compilers - not hard to hook in other toolchains
(easier/less error prone than cmake)
-Cross language under a single build system - python, sh, c/c++, go,
obj-c - all have first class support and can "see" eachother in terms
of dependency tracking/targets.

I have built alot of software against bazel - hdf5, boost, and common
simple libraries like tif/png/jpeg, zlib to list a prominent few and
it's taken those projects like a champ - generally being smooth
sailing.

Could it have done better or easier?  Yes hdf5 for instance is
trickier than most due to autoconf based configuration - I hope things
will keep getting easier with it (bazel).  That happens one project at
a time, but mega projects like qt can be instrumental in making that
happen - both solving the problems unique to qt on bazel (changing
things that needed to be changed) as well as providing the
interface/build rules to correctly use qt6 (official sdk, system
installs etc) - both being amplifiers of usage.

Cross-platform prebuilt binaries are available from here:
https://github.com/bazelbuild/bazel/releases - it can be done fairly
stand alone from distribution (by design) though - it's not too hard
to package as a deb, rpm, or tar, even if you don't use the
facilitated methods of doing that.

-Jason