Interesting. My friend, who works at well known gaming company you've probably heard of, recently spent several months of his life fighting back against a group of people that came in from an acquisition that were trying to convert the company's well-working CMake system over to Bazel. He described it in pretty poor terms and described how it constantly caused the build system to fail. He eventually succeeded in convincing management to keep the CMake system rather than converting it to Bazel at the objection of the more senior devs from the acquisition.
It’s a somewhat steep learning curve, but in my experience once you have your Bazel rules set up properly, it’s incredibly powerful, enabling lots of time savings from caching, as well as helping enforce reproducible outputs.
I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds. But the work has to be done, and there's a lot of unlearning to do.
If your project doesn't take long to compile or test anyways.... I can see getting annoyed.
> I feel like Bazel is much more convincing _after it's working_, cuz you really do get much faster builds.
I have to call bullshit on this claim.
CMake is at its hear a build system generator. It offers a high-level abstraction to define software projects, and it uses that abstraction to generate the actual build system. It can generate makefiles, but also Ninja, Xcode, visual studio, and even msbuild projects.
What actually does the build is not CMake, but make, msbuild, ninja, Xcode, or visual studio. Not CMake.
You run CMake once to generate the build project, and when you actually want to build the project you only call ninja or make etc.
To top that off, some of these build systems support build cache systems such as sccache or ccache. Plugging in one of these tools can easily drop build times to a fraction of the time. Literally. I had C++ projects which used CMake whose build time of a complete rebuild dropped to 15% of it's original time.
