> "Of course our build takes long, we have over 10,000 lines of code!"
Well, my project misses the 10 minute target by a factor of four, but does include tests and have 670kloc of C++. I claim continuous in this context, thanks very much.
Well, my project misses the 10 minute target by a factor of four, but does include tests and have 670kloc of C++. I claim continuous in this context, thanks very much.
We managed to get it down under about 15 minutes for the most common platform by using concatenation builds. It's much much faster to build half a dozen files than a thousand.
At a previous employer we were up to 1.25mloc by the time I left and we had a different solution: ccache+distcc distributing the build across a room full of computers. Few files took longer than 5m to build all by themselves, and the link phase also took about 5m.
(Splitting up large C++ projects that have grown organically is really hard. It requires re-architecting and commitment to spend time on this technical debt.)
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...
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.
I don't deny that can happen, but I have seen teams with build times that exceed 10 minutes that don't have issues. People aren't generally dumb, so they find a way to work that doesn't involve constantly sitting around waiting on the build.