3 ms·
In such scenario, ninja (or alike) would be the same thing to make as ccache to cc. But, the biggest single performance improvement of ninja comes from the fact
by sklogic 12y ago
In such scenario, ninja (or alike) would be the same thing to make as ccache to cc. But, the biggest single performance improvement of ninja comes from the fact that it's a single source for the whole tree - while make calls itself recursively, slowing down the dependency discovery and defying the caching potential.
- justinsb 12y agoI don't think I've properly explained the idea... The goal is to get the same performance as ninja, in the common case when the dependencies/build steps haven't changed. We somehow use the makefile to generate the ninja file; likely by executing make and capturing the dependencies & commands (without executing the build commands). But we don't encode the full complexity of the makefile in the ninja rules; if someone adds a file or changes a flag or even adds a #include directive, our ninja rules will be out of date. So we are able to run the build entirely in ninja, but we may not be building what the makefile would build. So we have to 'waste' some CPU time running the make -> ninja conversion in parallel to verify that our ninja build is still correct, but as long as 'total ninja build time' > 'make to ninja conversion time', we come out ahead in wall clock time.
- jessaustin 12y agoI've never used ninja, but ISTM the ninja setup would just need a few dependencies on the Makefiles themselves in order to build its own Ninjafiles (or whatever they're called). After all, if it's a build system, it surely knows whether or not depended-upon files have changed! Then there would be no need for "parallel" runs or error-prone diff'ing.
- Nursie 12y agoMake only calls itself recursively if you build the Makefiles that way. It's possible to have flat, all in one Makefiles and use include files for different targets etc.