Race condition in Build?

[mpilman]

I have a project that implicitly depends on swift-nio-ssl (through GRPC and PostgresNIO I believe). When I am building on Linux Arm64 (not yet checked on amd64) through docker I sometimes get the following error:

Building for debugging...
In file included from /src/.build/checkouts/swift-nio-ssl/Sources/CNIOBoringSSL/crypto/bytestring/unicode.c:15:
In file included from /src/.build/checkouts/swift-nio-ssl/Sources/CNIOBoringSSL/include/CNIOBoringSSL_bytestring.h:18:
In file included from /src/.build/checkouts/swift-nio-ssl/Sources/CNIOBoringSSL/include/CNIOBoringSSL_base.h:64:
/usr/lib/clang/13.0.0/include/stddef.h:103:10: fatal error: could not build module '_Builtin_stddef_max_align_t'
#include "__stddef_max_align_t.h"
 ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

The reasons I believe this is a race:

1. I don't see this problem always
2. This seems to happen on clean builds only
3. Running swift build after this happens seem to resolve the issue

[Lukasa]

This does not seem likely to be a timing issue per-se: I don't see how a timing window is likely to lead to that header being present or not present. However, in either case this seems likely to be a swift-package-manager issue more than a swift-nio-ssl issue, can you file an appropriate issue on that repository and link it here?

[al45tair]

Sounds like it might be a missing dependency arc somewhere; in parallel builds, those turn into race conditions and issues where things build when clean, or build on the second attempt and so on.

[Lukasa]

You think the dependency arc is missing in Clang's headers?

[al45tair]

Not certain where the problem is, but it's usually the reason for "flaky" builds. It'd be nice if there were a more explanatory error — this is very much a "something didn't work" :-(

[0xLucasMarcal]

@Lukasa We're having the same issues with flaky builds here, but for a different reason

It's not currently possible to do it only with SPM, but would love to have swift-nio and all it's dependencies packed into a static library, I wasn't able to do it only with Swift Modules because of some non-swift code like CNIOAtomics.
Currently we're importing swift-nio-* because swift grpc heavily relies on it, but the build times are huge. That's the reason why I want to pack it on prebuilt artifacts and share it between builds. Besides that, it would also fix the flaky build thing

[0xLucasMarcal]

@al45tair @Lukasa
Here's a more detailed output log
swift-nio-ssl.log

[Lukasa]

error: the following command failed with exit code 0 but produced no further output

This seems to be fundamentally different than the original issue here. That looks to me like a SwiftPM problem: how are you trying to build? What build command are you running?

[0xLucasMarcal]

We have a normal Xcode iOS app that depends on some local SPM modules, one of those modules depends on grpc-swift.
The build command is a normal xcodebuild build.

Also, all the grpc-swift and it's dependencies takes really long to build, and since SPM doesn't have a robust cache (remote or local) infra, would love to have a pre-built release of the swift-nio-* libraries, this would cut our build times in half. (If it's not possible to be done in the public repo, would love to hear some tips of how to do it on our side)

[Lukasa]

The build command is a normal xcodebuild build.

Hrm, this seems like an Xcode issue. Can you file a bug report using feedbackassistant.apple.com and provide the FB number here?

Also, all the grpc-swift and it's dependencies takes really long to build, and since SPM doesn't have a robust cache (remote or local) infra, would love to have a pre-built release of the swift-nio-* libraries, this would cut our build times in half. (If it's not possible to be done in the public repo, would love to hear some tips of how to do it on our side)

There is no way to provide pre-built releases in the SwiftPM ecosystem today unfortunately. This would be a good feature request for SwiftPM though!

[0xLucasMarcal]

Going to file a bug report then.

Got it, some libraries does it, but I think the dependency resolving times are really slow though.
But, if the swift-nio-* libs had some .xcframeworks as release assets, it would be pretty easy to integrate with other dependency manager systems. Our app uses mostly grpc-swift code, but we are not being able to pack it into a static library /XCFramework and distribute it because it doesn't support umbrella modules. And packing every dependency would be very hard to maintain it all up-to-date along the months.

[Lukasa]

We deliberately do not offer xcframeworks as the SwiftNIO projects do not provide a stable ABI.