Being written in Java is essentially a non-issue. Bazel ships as a binary that self-extracts a JRE for its own use. You don't have to install Java unless you want to build Java apps.
The real issue for highly reusable products like Qt is portability of the build tool. CMake works on the long tail of OSes, some of which do not have any usable JRE available. That limits the ability to use Bazel as the only build tool.
For Bazel to be useful to projects like Qt (and other horizontal libraries like openssl, ICU, curl, ...) one would need a system for generating CMakefiles from BUILD files. The developers of those apps could use Bazel to improve build and test scaling, and then generate CMake (or other build tool) files as part of their packaging and distribution. I don't propose that this is an easy thing to do - all rules would need translation into other languages - just that it is a path which may benefit some projects.
CMake may have a longer history of being used by open source, but Meson has been growing in popularity for some important projects. I definitely prefer Meson to CMake.
Bazel is also a great build system, but yeah, the JRE dependency will obviously make it less desirable for some users. Still, I hope people consider it anyways, because its focus on correctness is pretty great.
Last time I checked meson still doesn't have great Qt support e.g. it can't track rcc dependencies [0]. Funnily enough that issue is about rcc not making dependencies available to the build system, but I believe it actually started doing so somewhere down the track. I did a little work on it a couple of years back but regrettably never followed up [1].
Non-sense. It only needs to support the toolchains and OSes people actually want, by no stretch of the imagination does it have to support all of the same stuff CMake does. It is not a non-starter for many.
It is the build system of lots of projects already, not just GNOME but also freedesktop stuff too, libinput is one.
Scons and qmake both predate CMake. It’s weird to characterize them as trying to “overtake” CMake; that’s not really a thing I think happened. As a matter of fact, there was a time when qmake was a better option; it was a fairly complete Makefile generator that had good support for subprojects and out of tree builds.
Then again, this is all irrelevant. What these projects all had to offer at one point is historical. Qt has to leave qmake because of qmake. During that time they evaluated many options, including a fairly innovative design called qbs - Qt Build System. In the end, the choice of CMake makes a lot of sense, as it is clearly the best available choice that had ecosystem support. Qt is unlikely to switch build systems again soon.
This entire argument has happened before, but instead of meson vs CMake it was CMake vs autoconf. The thing is, I suspect CMake will still exist even as Meson inevitably continues to gain traction, just as autoconf (unfortunately) exists today.
There is, in fact, room for more C++ build systems, and almost definitely room for better interop. (Meson and CMake have some interop today.)
> Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else
It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. I simply don't have time to write a program in a slow, stringly-typed, ad hoc DSL just to build my actual program.
At work, we use cmake; i've never seen a technology with so little 'traction'; I know one guy who is good with cmake all the other (including me) avoid touching this thing as much as possible!
Sigh, I remember debugging a complex makefile generation issue (it took me 3 days, two guys before me failed) and it didn't make me hate the make tool, I just wished it had better tracing/debugging but cmake that's a different story..
Most _C++_ projects are using CMake, but it has virtually no adoption among other mainstream languages, and given most open source is not C++, CMake definitely doesn't have any strong share of the open source market.
My comment was about Qt, which is a C++ project. Of course CMake doesn’t have any market share outside of C++, but in the C++ world it has become the main build tool for open source projects. Even Microsoft is now spending their time supporting CMake via both Visual Studio and vcpkg.
(Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)