When comparing Apache Ant vs Tup, the Slant community recommends Tup for most people. In the question“What are the best general purpose build systems?” Tup is ranked 3rd while Apache Ant is ranked 10th. The most important reason people chose Tup is:
It is very fast.
Ranked in these QuestionsQuestion Ranking
Pro Good for special projects
Ant is an imperative build system, this means that it's very good at controlling the build process. You "tell" Ant what to do during the whole process, for example: "compile these files and put them in that folder". This is great for special projects where you want as much control as possible during the build process.
Pro Agile Dependency Manager (Ivy)
Ivy is a powerful tool for managing dependencies. It's highly configurable and very flexible and is not tied to any specific structure or architecture.
Although it can also be used as a standalone tool, it's tightly integrated with Ant and provides all the dependency management services for it, basically transferring all of Ivy's flexibility in dependency management to Ant as well.
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.
Con Too much freedom
While it's true that Ant gives you a lot of freedom and control over your builds, it also means that you will have to constantly reinvent the wheel on how your project structure and how everything fits together for every new project. This also makes it harder for other people to simply start working on your project because of the wide range of different ways to build a project with Ant. While tools that have more constraints generally end up looking the same and it's easier to understand how everything fits.
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).