Is anyone using Bazel to ship cross-platform GUI applications?
Is anyone using Bazel to ship cross-platform GUI applications?
By the sake of God no.
The last thing I need to compile Qt is a gigantic framework requiring the JVM. Plus the fact Bazel has so many side effect that that even quantum physics experiments looks more reproducible: Just try to compile tensorflow and enjoy the fun.
Stick to CMake, thanks.
Because CMake contrary to Bazel do not break its retro-compatibility in its options and config every two minor versions ?
> The latter builds in a clean room, Make does not.
Sandboxing should be the concern of the package manager / deployment pipeline, Not the build system concern. That just makes things redundant and painful to debug.
Lol that’s only recently true. CMake was infamous for breaking compatibility. Anyway, Bazel was pre-1.0 until just now, so of course expect some instability.
> Sandboxing should be the concern of the package manager / deployment pipeline, Not the build system concern. That just makes things redundant and painful to debug.
It makes things specifically very easy to debug. Not everyone enjoys troubleshooting issues on their machine due to their local environment.
(Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)
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.
[0] https://github.com/mesonbuild/meson/blob/27c01dff01832fa9d0c... [1] https://github.com/mesonbuild/meson/issues/97#issuecomment-3...
Meson will most likely be kept as the GTK, GNOME build system.
It is the build system of lots of projects already, not just GNOME but also freedesktop stuff too, libinput is one.
Everyone on C++ community is gravitating towards CMake, Conan and vcpkg, they won't migrate to something else now.
Scons, qmake, waf, premake, Gradle C++, MSBuild, ...
I know which horse to bet on.
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.)
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.
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 projects are using CMake nowadays : https://www.jetbrains.com/research/devecosystem-2018/cpp/
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.