3 ms·
Not bashing at all (you are somewhat in a better place than my own organization) but a point could be made that you could break the code down into subprojects a
by marcv81 10y ago
Not bashing at all (you are somewhat in a better place than my own organization) but a point could be made that you could break the code down into subprojects and manage dependencies.
- verytrivial 10y agoIndeed it could, and you're looking at the result, down from 2.5h-ish when I arrived. Our pipeline runneth deep ... (Though of course we'll never stop whittling!)
- marcv81 10y agoAw man!
- deleted 10y ago[deleted]
- MaulingMonkey 10y agoI'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 10y agoI 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.