[Development] Qt 6 buildsystem support requirements

[Matthew Woehlke]

On 2018-07-21 19:52, Jason Newton wrote:
> 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 [...]

No. Just, *no*.

Persistent build server? Java? No, thanks.

Maybe it's gotten better, but last I knew, bazel had no notion of
"installing" software, which is just a non-starter. It's also heavily
optimized for Google's internal usage, and (partly as a result)
basically does not play at all nicely with software that's intended to
exist in an open source, package-managed ecosystem.

(I'd be interested to know if there is *any* software packaged by any
FLOSS distribution that uses bazel...)

Basically, ask your distributors before even *considering* bazel. My
suspicion is they're going to tell you that they refuse to package
anything using it.

And... seriously, *Java*?! Talk about bloat-ware... As dependencies for
*a build tool* go, that's pretty insane. Especially if you're not
planning to use it to build Java code.

By comparison, CMake+ninja depend on... a C++ compiler. (Which is also
needed for Qt itself, of course, so...) I haven't really looked, but I'd
guess qmake is also pretty light-weight in the dependency department.

> Why the qt project may be interested in this in short is:
> -Fast and scaling bazel uses a long lived server technique that hangs
> around

Yeah... that's *just* the sort of thing we should be forcing on users...
It's even *more* of an anti-feature if some other build systems needs to
build Qt. (Yes, that happens.)

On a related note, "hermetic builds" is pretty ironic. Your *build*
might be hermetic, but bazel itself is *far* from... it's very reliant
on putting all its garbage in "magic locations" in your home directory,
unlike most build tools that only need to write to your build directory.
Again, *not* friendly for anyone that needs to build Qt as an external
dependency.

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

Um... very few projects don't work with Ninja, and I've seen plenty of
very large projects that *do*.

> -Ability to build external libraries from source

Yeah... no. Building third party libraries yourself is *evil*. And a
great way to piss off package maintainers. No open source project should
*EVER* rely on, or preferably even use by default, this ability.


On 2018-07-22 06:11, Kevin Kofler wrote:
> There is also little to no documentation on packaging Bazel-using software 
> for GNU/Linux distributions. E.g., the Fedora wiki does not contain a single 
> reference to Bazel.

There's a *reason* why that's so...

-- 
Matthew