Distribute a prebuilt swift-syntax binary

[petrpavlik]

Description

I think that it'd be great to also distribute swift-syntax as a prebuilt framework with every release, at least for Apple platforms (like https://github.com/realm/SwiftLint does).

We have been successfully experimenting with https://github.com/sjavora/swift-syntax-xcframeworks because the added build time to our CI builds when compiling swift-syntax from the source code is unacceptable.

[ahoppen]

Tracked in Apple’s issue tracker as rdar://120712265

[kingnight]

Strongly agree with this suggestion

[asam139]

Tracked in Apple’s issue tracker as rdar://120712265

@ahoppen can you give an estimation? For huge projects the initial compile time is a huge factor so it can be integrated

[vmanot]

@ahoppen would love to know if there's any estimation available regarding a fix, this is a showstopper for our team! 🙏

[ahoppen]

The challenging part of this is to also support platforms Linux and Windows as well as cross-compilation. We are aware of the issue and will post an update once we have it.

[vmanot]

@ahoppen given that Package.swift supports platform conditionals (i.e. #if os(macOS)), I'd imagine that a temporary patch for Apple platforms (perhaps one pointing to XCFrameworks just for Apple platform builds) would unblock a lot of teams on adopting macros and immediately free up developers from a massive amount of pain experienced on a daily-basis right now.

This issue has been plaguing adopters since the release of Swift Macros. I completely understand and fully support the desire for a fix that supports Linux and Windows, but my understanding is that SwiftPM's current support for XCFrameworks is capable of solving this issue today for Apple platform developers, in a conditional manner that will not disrupt Windows/Linux builds.

There are many folks who've already demonstrated a fix (see InstantSyntax, BinarySwiftSyntax etc.) and the only reason their fixes cannot be widely adopted is because SwiftPM is unable to reconcile a name conflict with swift-syntax (i.e. even if InstantSyntax vends the exact same products as swift-syntax, packages that depend on Apple's swift-syntax will have their dependency on it conflict with InstantSyntax).

Simply adding SwiftSyntax as a dependency can increase Xcode Cloud build times by up to 12 minutes. It has absolute wrecked release build times, and Xcode's inability to reuse build products for even unchanging dependencies across schemes/branches means that this cost is incurred over and over again during a typical work session with a moderately complex project that adopts macros.

Furthermore, Xcode 15's accruing instability necessitates frequently cleaning DerivedData to fix ghost errors/warnings across projects, and Xcode currently does not offer an option to clean the derived data while preserving build products/artifacts for fixed dependencies. This means that swift-syntax and its dependencies is rebuilt in debug mode multiple times as well. This isn't an issue with the swift-syntax project of course, but it is a practical consideration given that a large majority of folks using swift-syntax right now are only using it because it is a practical requirement for Swift macro targets.