Individual developers more often than not build large projects in parallel to speed the process up with 'make -j <something>'.
OS distributions would also prefer to enable parallel builds by default. But there is a problem of deciding if it's safe to build a package in general. In small projects developers frequently forget that their Makefile might be used in a 'make -j' setting and don't test the scenario. Recently I attempted to enable 'make -j $(nproc)' instead of 'make' for the whole NixOS software collection. I found quite a few build failures. Most of them have very easy fixes. The good simple example is 'cramfsswap': https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996964 There one of the targets uses effect of another target, but does not declare it. Contrived example: # Makefile: all: a b a: touch a b: cp a b Here 'make all' happens to work, but 'make b' alone does not. This made me thinking: what could GNU make do to make these types of errors more obvious? I cane up with two ideas: 1. Enable parallel builds by GNU make by default, so 'make' would mean 'make -j $(nproc)' unless asked otherwise. Some build systems (like ninja or waf) already do it. While sounding drastic I think it's a reasonable change longer term. 2. Do not run dependencies in deterministic order by default: Even when make is ran sequentially GNU make could do some effort to reorder targets to have a higher chance of executing steps in unexpected order. A possible implementation would be to pick a random seed at GNU make startup and perform target order permutation when allowed. If build were to fail random seed would be printed along with failure message. That way it would be trivial for others to reproduce the failure. Sometimes build failures are very hard to replicate. I think both are worth implementing. What do you think? Would it be reasonable to implement any or both of these changes for GNU make? Thanks! -- Sergei
