bazel is a turing complete, extensible build system, so if your core build is done with bazel is there any reason to use anything else? In theory, no. You can do anything with a collection of bazel rules and targets. In practice though, bazel isn't the simplest of systems to use, and the best tool around to understand what bazel is doing is bazel query, so there's a bit of a chicken and egg problem there. Your IDE isn't much help either. Many of them can do syntax highlighting, but they don't tell you why something was built or which rule(s) got fired.
On the other hand, Makefiles can't handle the depth/complexity of the trees we build, or at least not simply, and they just don't provide the power/flexibility to only do exactly the things you want done. They're also strangely prescriptive about the format of the Makefile itself. Not quite COBOL, but leading whitespace is important (and mostly invisible). But they are pretty simple to understand since the basic rules are simple.
So what's an engineer to do? For your actual build, bazel is a good choice, especially if you're in a world with lots of other bazel things (NA, Sim, atg-services, etc) then do your build in bazel. If you're not, consider it. After all, we're heading for a monorepo with the majority of the build being managed by bazel.
But there's another use case for Makefiles. Simple scripting to make your life easier and reduce typing. That's the Makefile of phony targets. It's a simple way to build/share a workflow and integrate 3rd party tools into a workflow, possibly including a bazel build <big long string of characters denoting the target>. you can even pass in arguments to help specify what you want to do. In that case Makefiles make sense, at least for a while. If you find yourself building/sharing complex Makefiles that's probably an indication that you should be talking to the DevX team about better shared tooling.
So what do you think? Makefiles, bazel, or some combination? Share in the thread.