4 ms·

Checkout ninja-build. Generate ninja build files automatically using CMake. Ninja is really fast.

rspeer 10y ago
Ninja is definitely the best and simplest build system I've used. A great example of the "do one thing and do it well" philosophy. The drawback comes from the simplicity: all dependencies have to be explicitly listed, which you probably don't want to do by hand, so you need some other tool to make the dependency list. I haven't seen how CMake works for this purpose, and I'd like to know more. What in particular do you do with CMake to use it with Ninja?
- anderspitman 10y ago
  cmake -GNinja ..
KKKKkkkk1 10y ago
I can understand why tup would be faster than make for certain projects - when you have many targets and intermediates, it's more efficient to probe only the source files. But with ninja, it's not clear why would it be faster than make. I can see how a simpler file format makes processing the build faster, but ultimately ninja seems to be generating the same amount of IO as make.
- iainmerrick 10y ago
  It does seem like it should be the same as make, but Ninja really is faster -- it just has close to zero cruft, whereas make is absolutely full of cruft. I use Ninja to build a medium-sized C/C++/ObjC project, around 1000 source files, and the dependency scan only takes a second or two. After that, it runs as fast as the compiler and linker are able. Edit to clarify: there might not be much speed difference for a full build, but incremental builds are much faster in Ninja.
  - sriram_sun 10y ago
    Yeah dependencies. Incremental builds are much faster. Try a make clean vs ninja clean. Ninja is a whole lot faster. I just rewrote the build scripts for a qnx makefile based system in CMake. The ninja build files brought down the build time from approximately 18 mins. to 5 mins! Incremental build time came down from 7 mins to about 30 seconds! Admittedly this was probably an extreme case where consultants got comfortable charging by the minute. Send me an email if you are interested in moving to CMake. I'll be willing to consult.
wahern 10y ago
CMake-generated ninja builds aren't fast in an oranges-to-oranges comparison: http://www.kaizou.org/2016/09/build-benchmark-large-c-project.html (TL;DR: scroll to bottom of page to see "The raw results".) A non-recursive Make build is actually pretty darn peppy for all but the largest projects. The reason ninja was faster at scale in those tests was likely because GNU Make has some very inefficient code internally which theoretically could be improved substantially with some refactoring. ninja had the benefit of a fresh implementation, avoiding decades of feature creep. I've been writing non-recursive-style Makefiles for years. But all I ever hear is whining by project contributors about the unfamiliar syntax (e.g. having to prefix all targets and sources with a path). Yet in the same breath I'll be told to use CMake or ninja or tup or whatever the build-system-du-jour, using vastly different syntax. Ah well.... I keep dreaming of a Makefile generator that will auto-generate a non-recursive build, or perhaps add the feature into GNU Make directly. The problem with the latter approach is that one major reason to use Make (including GNU Make) is portability out-of-the-box, but OS X is stuck at GNU Make 3.81.
- sriram_sun 10y ago
  Thanks for the info. I just looked into it. You are right about non-recursive Makefiles. My own experience with cmake generated makefiles are actually comparable with ninja build times. Why would you want to write Makefiles by hand anyway? With CMake you can generate VS 2015 or MinGW or ninja pretty much any project file. QtCreator deals with CMake project really well. KDevelop too. I think CMake is the way to go. Then we won't be talking about ninja vs. make vs. tup

Ninja is definitely the best and simplest build system I've used. A great example of the "do one thing and do it well" philosophy. The drawback comes from the simplicity: all dependencies have to be explicitly listed, which you probably don't want to do by hand, so you need some other tool to make the dependency list. I haven't seen how CMake works for this purpose, and I'd like to know more. What in particular do you do with CMake to use it with Ninja?

anderspitman 10y ago
cmake -GNinja ..

KKKKkkkk1 10y ago

I can understand why tup would be faster than make for certain projects - when you have many targets and intermediates, it's more efficient to probe only the source files. But with ninja, it's not clear why would it be faster than make. I can see how a simpler file format makes processing the build faster, but ultimately ninja seems to be generating the same amount of IO as make.

iainmerrick 10y ago
It does seem like it should be the same as make, but Ninja really is faster -- it just has close to zero cruft, whereas make is absolutely full of cruft. I use Ninja to build a medium-sized C/C++/ObjC project, around 1000 source files, and the dependency scan only takes a second or two. After that, it runs as fast as the compiler and linker are able. Edit to clarify: there might not be much speed difference for a full build, but incremental builds are much faster in Ninja.
- sriram_sun 10y ago
  Yeah dependencies. Incremental builds are much faster. Try a make clean vs ninja clean. Ninja is a whole lot faster. I just rewrote the build scripts for a qnx makefile based system in CMake. The ninja build files brought down the build time from approximately 18 mins. to 5 mins! Incremental build time came down from 7 mins to about 30 seconds! Admittedly this was probably an extreme case where consultants got comfortable charging by the minute. Send me an email if you are interested in moving to CMake. I'll be willing to consult.

wahern 10y ago

CMake-generated ninja builds aren't fast in an oranges-to-oranges comparison: http://www.kaizou.org/2016/09/build-benchmark-large-c-project.html (TL;DR: scroll to bottom of page to see "The raw results".) A non-recursive Make build is actually pretty darn peppy for all but the largest projects. The reason ninja was faster at scale in those tests was likely because GNU Make has some very inefficient code internally which theoretically could be improved substantially with some refactoring. ninja had the benefit of a fresh implementation, avoiding decades of feature creep. I've been writing non-recursive-style Makefiles for years. But all I ever hear is whining by project contributors about the unfamiliar syntax (e.g. having to prefix all targets and sources with a path). Yet in the same breath I'll be told to use CMake or ninja or tup or whatever the build-system-du-jour, using vastly different syntax. Ah well.... I keep dreaming of a Makefile generator that will auto-generate a non-recursive build, or perhaps add the feature into GNU Make directly. The problem with the latter approach is that one major reason to use Make (including GNU Make) is portability out-of-the-box, but OS X is stuck at GNU Make 3.81.

sriram_sun 10y ago
Thanks for the info. I just looked into it. You are right about non-recursive Makefiles. My own experience with cmake generated makefiles are actually comparable with ninja build times. Why would you want to write Makefiles by hand anyway? With CMake you can generate VS 2015 or MinGW or ninja pretty much any project file. QtCreator deals with CMake project really well. KDevelop too. I think CMake is the way to go. Then we won't be talking about ninja vs. make vs. tup