4 ms·
It’s nice to drop back to serial compilation when debugging IMHO. Sometimes one header bug causes two errors with interspersed output in parallel builds.
by pletnes 8y ago
It’s nice to drop back to serial compilation when debugging IMHO. Sometimes one header bug causes two errors with interspersed output in parallel builds.
- tom_ 8y agoNinja serializes each tool's output. (I imagine it buffers the output internally. With a moment's thought you can imagine situations specifically engineered to cause more problems than this solves, but I've been using Ninja for a couple of years now and I've yet to see that happen.)
- pletnes 8y agomake -O does the same. In fact, it can serialize a whole target, at the cost of buffering that output.
- tom_ 8y agoAwesome ;) - thanks for this note. I've been using the same no-dependency no-cygwin Windows build of 3.80 for about ten years, and OS X comes with 3.81, so my GNU Make skills never got any further than that. But this has prompted me to track down a similar Windows build of GNU Make 4.21, so all I need to do now is figure out how to get one set up on OS X... This won't get me to switch away from Ninja when using CMake, but I write my own -j-friendly makefiles sometimes, so this will come in handy.
- cbcoutinho 8y agoThat's a good point, but I'm debugging much less often than running make, so when I want to disable parallel builds I just `unset` the MAKEFLAGS variable. For me this is a nice default.