By 'faster' I mean better build times than Make for a project of particular size. Benchmarking is going on right now, and the difference in performance is clearly visible.
Make is rarely a big bottleneck, except in very pathologically written projects, and when doing incremental builds. I think the main problem with big make setups is recursive make, which prevents it from having a global view on the project, and forces the main make to execute many sub-makes recursively, all of which has overhead.
Good point. I have to say I'm wary of that, recursive make is not a good idea, and the problem can't be fixed by building a better make, because the issue is that it breaks up the dependency graph and creates build problems.
Eg, if you have src/lib, and src/bin, and the src/bin project depends on the src/lib library, then in self-contained, recursively invoked makefiles (or anything else), you won't get a correct behavior when a header in the library changes.
What do you mean? make has no particular requirements regarding the file structure. You can write a single giant Makefile covering a directory tree with thousands of source files in various directories.
I meant independent of the (make-replacement)file structure. As long as the dependency graph isn't restricted to a single build file, then most of the inherent issues with recursive make are avoided.
Make is rarely a big bottleneck, except in very pathologically written projects, and when doing incremental builds. I think the main problem with big make setups is recursive make, which prevents it from having a global view on the project, and forces the main make to execute many sub-makes recursively, all of which has overhead.