Motivation
Generators
Many existing build tools fall into the category of build script generators. These are not build systems in their own right. They rely on an existing build system in place to do the hard work of maintaining dependencies, executing the tools, parallelizing or distributing the builds, handling the logs, etc. As such they inherit the shortcomings present in the underling build system and necessitate an extra build step, while solving only the portability issue to some extent.
For example MSBuild can't parallelize files within one project thus impacting build times in some circumstances. Using CMake does not lift that limitation.
Offenders: autoconf, CMake, premake.
Stateless
Many build systems don't persist any state of their own, and rely solely on the filesystem metadata of the generated files. Such build systems cannot reliably detect which files were modified.
For example: if a file is rolled-back, Make won't detect that it was changed and won't rebuild the dependents.
Offenders: Make.
Directory hierarchies
In a repository with hundreds of libraries and executables, building any single one of them shall not involve loading the build scripts for the entire repository.
At the same time, building the entire repository shall be supported as a single coherent process.
Offenders: recursive make, CMake.
Package managers
Brix is a build system, not a package manager. It will not automatically fetch or install dependencies from external repositories, though of course it can be coded as part of the build if necessary. Package management is part of the host system, not the build process.
Make
Makes of all sorts and kinds are very limited in their abilities: handling tree hierarchies, out-of-tree builds and dynamic dependencies are all impossible to properly achieve in any of them, yet none of them is truly portable. For a good in-depth article about Make flaws see What’s Wrong With GNU make? Brix tries to address every single point raised in that article.
MSBuild
MSBuild teaches developers to think of build systems in a harmful and terrible way. It has a notion of 'projects' and is incapable of parallelizing the build of files within a single project. This encourages fracturing the codebase into lots of tiny projects, then forces you to manually specify the dependencies between them. Too few projects and changing one file relinks everything that might not even truly depend on it. Too many projects and you'll drown in specifying all the dependencies by hand. In the limit you would need a separate project for every file to achieve the degrees of parallelism provided by other build systems.
Item sets are harmful -- those will be built as many times as they are referenced, exploding the build times on the way.
Brix solves this by specifying link dependencies per file, then taking a transitive closure of those. Moreover, those dependencies can be automatically detected based on the includes. And the mechanism isn't specific to headers or C++ in any way.
SCons
Requires Python. 'Nuff said.