If that means that there will be no check in advance for printf: hell yes.

Perhaps the error printing during a parallel build could also be improved somehow.

Honestly? If the question is if I would A) make everyone everywhere spend minutes (or potentially hours on Windows) all the time running the configure script any time anything changes, or B) not spend all that extra time running configure but maybe get a compile error a few minutes later if I'm compiling on extremely weird systems (such as ones without printf), I think I'd take B.

Especially since configure doesn't actually make anything any faster even in most cases where it _does_ detect errors. It aborts at the first error. So when I'm missing packages for example, I will wait half a minute while `./configure` runs, then it errors with a single missing package, then I will install that package and re-run `./configure`, wait another half a minute until it prints another single missing package, etc. Repeat until I have all packages.

I hate autotools so much. Configure scripts should either run in parallel, or cache its results, or both (ideally both), and they should report as many errors as it can before aborting.

I would rather the printf check be handled by the compiler than in the configure check because the compiler will of course know that printf is present and not waste your time.

ninja solves that parallelism-issue quite nicely. So do most IDEs.

IME, ninja doesn't solve that issue. At least not in the versions I've used.