[MaulingMonkey]

I've been on projects that did this - just linking everything back together if you touch a widely used subproject can blow that 10 minute budget too, for a single build flavor. When porting things for game development, I routinely have 30+ build flavors (say, 5 platforms, 6 configs per), and want to test at least a few of them to have even a remote chance of the checkin going green when touching core platform abstractions or config-specific stuff.

A lot can be done to reduce your typical or average build times (make everything data driven so you don't even have to rebuild the code!), but C++ makes it very hard to keep your worst-case build times in check. And I tend to be one of the guys tweaking and fixing things that invoke those worst-case build times. A simple example: Annotating logging macros to catch printf-style format string errors at build time instead of crashing at runtime if you're lucky.

Properly testing involves rebuilding most source files, on at least 3 build flavors to test against MSVC, Clang, and GCC...

[solarengineer]

I quite agree with you!

I'd enjoy working on this :) It looks like a nice application of true build pipelines using GoCD. If you're interested to discuss this offline, do let me know.