The Swift toolchain uses CMake and Ninja. In a nutshell, CMake in a (much) fancier Autoconf and Ninja is a multi-core -aware make equivalent. I tried configuring CMake to use make once to see how different the performance was and, well, let's just say I let it run for about a week before I decided to give up because I wanted to use my computer.
I started getting strange errors when building Swift using mock; it was dying with references not being found in libXCTest.so and before that, warnings that the file itself was empty right before the errors began. Since Apple hadn't updated the Swift 5 snapshot for awhile (this was with swift-5.0-DEVELOPMENT-SNAPSHOT-2019-03-10-a) I figured there was some update Fedora had pushed that caused this. Since I hadn't updated my host machine, it still built fine, so knowing that something was going to break it when I did an update, I ran dnf -y update and in addition to some kernel updates was an update to CMake to version 1.14. Running the build again and, yep, sure enough, it failed with the same error.
The problem was that `/home/rolson/rpmbuild/BUILD/swift-source/build/buildbot_linux/xctest-linux-x86_64/libXCTest.so` was in fact 0 bytes. Teasing apart the CMake file I was able to determine that the file itself was being built correctly, but there was an additional step from the CMake file that had the newly created .so file being copied into the same directory it was already in, and this step was causing it to be zeroed out.
So, armed with the CMake source code, I investigated what code was being executed when running cmake -E copy foo.txt . and sure enough, it turns out that the file was being deleted and recreated, resulting in an empty file. I asked in the IRC chat room if this was, for some reason, expected behavior but did not receive any response. I decided to go ahead and make an attempt at a patch (hey, I've been making patches all over the place for Swift, why not CMake too?) and opened a bug report complete with the suggested fix. Well, turns out the issue is a bit more complicated in CMakeland and while the patch is not ultimately useful, at least the CMake folks are on it.
Here's hoping that once a new CMake version is available and ultimately updated in Fedora, there's one more patch that can be retired from Swift 5.x on Fedora.