[dale_glass]

The style looks extremely similar to make, in which case it needs a good explanation of what makes it better.

It even seems to copy make's syntax, which IMO is a missed opportunity. One of the issues with Make is that the syntax is clever until you need to invoke multiple lines of shell script, like a loop. Then the tab-based cleverness becomes a pain.

[gaurav1804]

Hi! Basically it is supposed to do what Make does... but in a faster and more user-friendly way. Note that Make doesn't have the best syntax. But Beast has sort of a 'python' syntax. It supports strings and integers. Variable modification assignment. It even supports scoping (within and outside beast build rules).

Plus, it is an order of a magnitude faster than Make. All in all, I don't agree with the fact that it's syntax is similar to Make. Well for one thing it has legible special variable names like 'out' and 'dep'.

So yes, while it is a low level build system, it is an improvement over Make in terms of syntax and speed.

[dale_glass]

How is it faster? And faster at what?

[gaurav1804]

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.

[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.