https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9957
There's really two reasons that CI doesn't do parallel builds:
1. They've never worked.
2. CI runs parallel *jobs*, which is easier to optimize the CI path with.
3. Just because parallel builds work on all our CI systems doesn't mean they work everywhere.
Basically, from the day when the gmake build system was first written, there has been missing dependencies. Since gmake doesn't know about the dependencies, it can't parallelize the build safely. Simply playing with different levels of concurrency can find many issues with parallel builds, but it can't find them all... and there's not really any good tools to automatically generate the dependencies.
This all gets worse because once you miss dependencies, it's not-obvious when you end up with transitive dependencies that then trigger parallel builds... the thing that breaks the build isn't actually in your last commit.
So basically it's always been a lot of fiddly work that couldn't be automated and the developers just got used to it.
CMake dependencies are handled quite differently, so CMake *does* work with parallel builds. It's likely possible to extract the cmake dependencies and plug them into gmake (`sbbs3/extdeps.mk` is an attempt to fix the issue for sbbs3).
Really, what's needed is a tool that can check if everything used by a compilation unit is expressed as a dependency in the build system. If that existed we would make *that* part of CI, and there would be some reasonable confidence that the dependencies actually work. AFAIK, nobody has attempted to find/build such a thing for Synchronet yet.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net