A proper way of packaging swift-syntax dependent SPM library

Using Swift
, ,
1

This question has been asked before but I wasn't able to find a satisfactory solution yet, so I'm reposting to raise awareness.The problem is somewhat straightforward: Swift Syntax depends on a dynamic library _InternalSwiftSyntaxParser which is bundled with the toolchain.

Now, the first problem is that the @rpath in libSyntax looks for _InternalSwiftSyntaxParser in the wrong place, multiple places in fact, none of them being the Xcode toolchain. You can overcome this by packaging _InternalSwiftSyntaxParser with your app as a binary dependency, however, that leads to another problem. If the consumer of your package has a different toolchain version installed, he'll get something like this at compile time:

The loaded '_InternalSwiftSyntaxParser' library is from a toolchain that is not compatible with this version of SwiftSyntax

Now, I'm guessing another way to partially solve this would be to modify the @rpath and ship libSyntax as a binary dependency, but that wouldn't help much with the second issue either, if the consumer's toolchain doesn't match libSyntax version, it will still fail.

Is there a way to elegantly/maintainably solve this?
It's a quite unique situation I think and ideally SPM would be able to dynamically pick the right swift-syntax version depending on the installed toolchain (and also somehow mitigate the @rpath issue described above).

1 Like
2

I believe that as of this PR from November 2022 SwiftSyntax no longer relies on _InternalSwiftSyntaxParser because the parser was rewritten in Swift. If you use a release from after that PR (I think there is one?) you will no longer be coupled to the Swift version. If there isn’t a release you could pin your dependency to a specific commit on the main branch temporarily

4

@stackotter Thanks, I was unaware this was already fixed!
For those in a similar situation, you have two options, since there's no release that contains both the fix and targets 0.50700.X:
a) pin your version to a developer snapshot that has the fix and call it a day
b) update to the recently released 508.0.0 (or later, if you're reading this in the future), this will almost certainly break your current codebase, but migrating worths the effort since 508.0.0+ is much nicer and easier to work with

1 Like