> However, another way of writing your question is "if you removed the features of make that ninja doesn't have and then optimized the remainder for performance, wouldn't they match?" and that is maybe tautologically true -- that description is roughly what Ninja is, after all.

Not exactly. I'm asking if an implementation of the portable subset of Make people actually use (pointedly excluding GNU Make extensions) could be made nearly as fast as Ninja. That would have the advantage of running existing makefiles, as long as those makefiles weren't written specifically for GNU Make.

I think we are maybe talking in circles. :)

When you write "could be made nearly as fast as Ninja", I thought you meant you would change the code of Make or write a new tool. If you don't write a new tool and just use a subset of Make's functionality for your own Makefiles I'd expect those to be faster than your standard Makefiles, sure.

But "existing makefiles" typically use a mixture of GNU make-isms and other things that are not GNU-specific but still slow (e.g. from a skim of the BSD make manual I see lazy variable expansions and control structures). So if you're talking about implementing a subset of Make you're talking about something that's unlikely to be compatible with Makefiles seen in the wild. And then if you're not compatible with Makefiles seen in the wild you've effectively written an incompatible faster subset of Make, which brings us back to what Ninja is. (In case it's not clear, in Chrome's case the same code was used generate Makefiles and Ninja files with some relatively minor output differences -- the tools are that close.)

Perhaps there's some "common" subset of Make that covers some high percentage of build files seen in the wild that could be made faster. That could be valuable to organizations who want faster builds without changing anything. I vaguely recall seeing some commercial software that did this even -- as I recall, their value add was that they had tooling that would figure out how to run your Makefiles in parallel; though Make supports parallel execution, apparently this business found enough customers by just targeting those with underspecified Makefiles that weren't parallel safe and then fixing them!

Anyway, all of this is kinda moot because for 99% of projects Make is plenty fast. I even use Make myself for all my personal projects! In Chrome's case (what we wrote Ninja for) there's so much code that the build files themselves are over ten megabytes of text, so to parse that quickly you're at the level of worrying about avoiding memory allocations in the lexer, which is beyond what most people would care about.

There are plenty of shell scripts out there that are written for /bin/sh without using bash features; similarly, many makefiles just use the portable subset of make, such as POSIX make. I agree that you'd likely need to write a new tool rather than attempting to optimize GNU make or BSD make. But you wouldn't need to introduce a new syntax; you could just use the POSIX subset of make.

I was partly asking because a fast make-compatible build tool seems easier to switch to, and partly because I wondered how much of Ninja's performance depends on dropping the slow features of make versus adding new capabilities or new syntax.