When comparing GNU Make vs Bazel, the Slant community recommends GNU Make for most people. In the question“What are the best open-source build systems for C/C++?” GNU Make is ranked 3rd while Bazel is ranked 8th. The most important reason people chose GNU Make is:
Make takes advantage of the powerful UNIX shell, using it at it's full potential. STDIN and STDOUT are especially useful because of their versatility.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Uses the full power of the UNIX shell
Make takes advantage of the powerful UNIX shell, using it at it's full potential. STDIN and STDOUT are especially useful because of their versatility.
Pro No need for wrapper modules
Other build tools need wrapper modules to do certain tasks. The biggest disadvantage of these wrapper modules is that they bind you to a version of that tool. With Make you don't have that problem, there's no need for wrappers and no tools to bind you to a version, you can use any version of Make that you want.
Pro Works with more than just node.js
Since it's written in C and can be found in all UNIX-based systems it can be used on platforms other than node.js.
Pro Correct and repeatable builds
Builds only use input files that are explicitly declared in the build specification. On Linux, Bazel runs tools in a sandboxed environment that contain only the minimum necessary files required.
Pro Fast even at scale
Even at large scale it's pretty fast (it's based on what Google uses internally for their huge code base).
Pro Can rule shell commands
Pro Handles mixed language builds
Pro High level build descriptions
Pro Build rule errors are informative
When builds fail because of an issue in the build rules, the errors provided are usually very informative and helpful to resolve the issue.
Pro Good IDE support
Pro Standard protocol for remote execution and caching
Pro Remote execution of commands
Cons
Con Doesn't run on Windows by default
Make requires Cygwin/msys2/MinGW to run on Windows.
Con Draconian sandboxing, explicit inputs requirement
Requirement to explicitly name all inputs disqualifies Bazel for many workflows, e.g. those relying on tools that scan a directory tree themselves looking for files to process. Sandboxing as implemented in Bazel imposes further restrictions. If a command is successful when you type it in the shell, it should also be successful when pasted verbatim into a rule, but with Bazel it very often isn't.
Con Confusing for beginners
With so many capabilities, trying to implement with a simple project is overkill and unpleasant.