When comparing Tup vs Bazel, the Slant community recommends Tup for most people. In the question“What are the best open-source build systems for C/C++?” Tup is ranked 4th while Bazel is ranked 7th. The most important reason people chose Tup is:
It is very fast.
Ranked in these QuestionsQuestion Ranking
It is very fast.
It will automatically clean-up old files.
Not bound to C/C++.
Tup supports writing build definitions using Lua or Tupfiles.
Pro Cross platform
Supports Linux, OSX, and Windows.
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 High level build descriptions
Pro Handles mixed language builds
Pro Good IDE support
Pro Standard protocol for remote execution and caching
Pro Remote execution of commands
Pro Can rule shell commands
Con Variants not working on Windows
The solution for having different build configuration (think Release/Debug) is broken on Windows.
Con Cannot incrementally modify or delete files
Cannot incrementally modify files (e.g. LaTeX PDF, VISing and LIGHTing Quake maps, which takes the same BSP file as input and output), and will not delete files (e.g. rm build/*.o).
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.