When comparing Autotools vs Bazel, the Slant community recommends Bazel for most people. In the question“What are the best open-source build systems for C/C++?” Bazel is ranked 8th while Autotools is ranked 18th. The most important reason people chose Bazel is:
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.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Based on standard tools
It's a standard tool built over standard tools.
Pro Ubiquitous
It's a well established build system that is ubiquitous in the open source world.
Pro make distcheck
Build your project, run the tests, create a release tarball, unpack it with read-only sources, build it and run the tests. This should be the minimum standard for every build system, yet it seems hard to reach.
Pro Basic API for building anything: ./configure; make
The skills you learn for building one language still work when you build something else, even down to creating books for print from emacs org-mode.
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 Perl
Autoconf is dependent on Perl.
Con Autotools is far too complicated
It seems to add far too much complexity to projects. The build system has a tendency to be more complex than the actual projects that it's being used to build.
Con Poor documentation
In spite of its many years of existence, the available documentation leaves much to be desired.
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.