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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development