[dale_glass]

Okay, but what specifically is faster?

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.

[gaurav1804]

The build process is faster. There are a number of algorithms running (on several threads) while building. That is where optimisation kicks in.

[aidenn0]

I suspect they are benchmarking recursive make vs recursive beast; the very first example in the readme suggests recursion

[dale_glass]

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.

[aidenn0]

Other make replacements have solved this by making the dependency graph independent of the file structure. Hopefully beast does this too

[dale_glass]

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.

[aidenn0]

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.