(Warning: Topic shift, to make systems and Bazel)
Wondering what you don't like about it. Not to argue but to try to understand why.
If you are trying to build a user-space application (which requires compiling and linking from many source files), and you want to end up with one or more binaries, it is quite easy to use. It can build Android and iOS apps, and Docker and Kubernetes "packages" (none of which I happen to be interested in). The language used to describe the sources and targets is very simple, the syntax is clean and Python-like. So far, so great.
Problem 1: The location of the sources will be a single hierarchical directory tree. The output (for objects and executables) will be in a location determined by Bazel. If you want to put executables in interesting places (for example for a complex system test harness that you have written and that lives in a source directory, or for tools needed for further stages of the compilation), then either you adapt your existing workflow to the location where Bazel wants to put them, or you go into the barely documented corners of Bazel.
Problem 2: Using the same source base, I perform builds on 4 machines (one FreeBSD, two RPi running Debian, and one Mac), and installs on 3 machines (all but the Mac). On different machines, different build and install rules need to be used. I have to be able to modify compiler flags in a platform-specific way. I need to select different targets. For example, on the FreeBSD machine I need to build and install executables A, B and C, and install one /usr/local/etc/rc.d/A script and the corresponding /usr/local/etc/A.conf file. On the two RPis, I need to build executables U, V and C, and on each of them a different version of a systemd configuration file for U or V. On the Mac, everything gets built, nothing gets installed, but there the test harness needs to be build and executed (my Mac laptop is the fastest machine I have, and the test harness uses about 2-3 hours of CPU time). In addition to supporting different targets per machine/architecture, I also have different external dependencies. For example, on the Mac I don't need to depend on GRPC, instead I use a local RPC-stub library; my personal Python libraries are in different locations on FreeBSD versus Debian. Putting "conditionals" (if statements) into the build file is at the edge of what Bazel is comfortable with, and the documentation is not to my liking.
Note: We're not talking about cross-compiling here. Most of the code is actually in Python (so it needs little compilation). We're talking about having different targets and build rules, and those selections are platform- and node-specific.
Problem 3: Bazel is good at building artifacts that reside within the "environment", a set of source- and target directories. But I need the assembled artifacts to be installed in many places (see above). What I can't find is support for "make install", in particular with dependency tracking.
I'm sure any of these problems can be worked around within Bazel. But I happen to have a functioning (barely functioning, overly complex, and brittle) system of makefiles with if statements that call other makefiles, and maintaining that is currently easier than finishing switching.
YMMV. Matter-of-fact, if you are using a build cluster, and you are building large artifacts (systems that rely on thousands or tens of thousands of source files), Bazel is going to be much better than make.