https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9924

@Deuce Fair disclosure, I'm not too familiar with GNUMakefile, so this is just a vibe-coded PR. Tested and works, but whether it could be improved, or closed, I'll leave that to your discretion.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9935

There's a number of issues like this in Synchronet that block parallel builds. If you're actually tracking them all down, I'm happy to support... I had this working properly a few years ago, but since we don't use parallel builds in CI, it always breaks without people noticing.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9936

Looking at this though, this makes *every* file that's compiled dependent on CRYPT_DEPS which isn't correct. We want to express the dependency between the individual targets, not the implicit rules.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9956

I didn't know about the rest so I wasn't tracking them all down, not yet anyway. ;) Why aren't parallel builds done in the CI? If the CI doesn't test with parallel builds, I doubt I'll spend any time looking elsewhere.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9958

Doing this work in the `syncterm-1.9` branch is likely the wrong place to do it... that branch is close to release and any packagers will have either already switched to cmake or are already disabling parallel builds. For SyncTERM specifically, all of the crypto stuff is changed in master, so this would only help with the last legacy release.

Where this would be most valuable is in `master` so all future releases are fixed.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/merge_requests/719#note_9967

I've closed this and have an MR on master now.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net