How did you created the xcframework of SPM library

[Nikoloutsos]

Hello @sjavora and thank you for providing this. OOC I am interested to know how you created an xcframework from an SPM package. I am trying to do this on pointfree snapshot testing but without success.

Thank you in advance

[sjavora]

Hi, check out https://github.com/sjavora/swift-syntax-xcframeworks/blob/main/.github/bootstrap.sh, which is used to produce the binaries.

[carterTsai95]

Hi @sjavora, this is interesting approach.

Recently our team came across to create swift-syntax's xcframework to reduce the compiler time on iOS platform. I have few questions regarding this PoC since I notice that while building the wrapper in the script is using:

swift build --package-path $SWIFT_SYNTAX_NAME --arch $ARCH -c $CONFIGURATION -Xswiftc -enable-library-evolution -Xswiftc -emit-module-interface

• Do you have an example of consuming this in a package that’s meant to be used in an iOS project, or consuming it within an iOS projcect directly? We notice that with the swift build it only build the macOS's lib file. I also not pretty sure whether there is a configuration on swift build can change the arch to iOS.

• Have you considered using xcodebuild instead of swift build? What have you found to be the difference? Since some people suggest using the xcodebuild which available on Xcode 11 onward. I wonder is there any limitation not to use it?

For us we tried with using the xcodebuild but the target package can not recognize the library inside the swift-sytax-wrapper package. By using the xcodebuild we need to make all the library as dynamic. We notice that need to make it static after archiving. The ${Framework}/Products/usr/local/lib/ won't have the framework file. With dynamic's library, we can generate the framework file and export the xcframework. But the target package won't recognize the library inside the wrapper package.

Thanks for your time for reading and provide this interesting PoC again.

[sjavora]

@carterTsai95 macros should not need to run on anything but macOS. There shouldn't be a reason to build them for iOS... except that's not true in practice in if you put the macros directly in the same package (or project I guess?) as the code that uses them. Since we put our macros in a separate package, this problem doesn't apply to our app (see https://forums.swift.org/t/macros-and-xcframeworks/68122/37 and really the whole thread - this is the most info I think you can get on the topic).

Dynamic libraries are a no go as per this post.

As for xcodebuild, I did actually end up using it internally for some reason, but those changes haven't made it here yet. The problem was that you need to create the .a library file manually out of object files, because there is no way (that I know of) to have xcodebuild do that (info in the thread again).

[carterTsai95]

@carterTsai95 macros should not need to run on anything but macOS. There shouldn't be a reason to build them for iOS... except that's not true in practice in if you put the macros directly in the same package (or project I guess?) as the code that uses them. Since we put our macros in a separate package, this problem doesn't apply to our app (see https://forums.swift.org/t/macros-and-xcframeworks/68122/37 and really the whole thread - this is the most info I think you can get on the topic).

Dynamic libraries are a no go as per this post.

As for xcodebuild, I did actually end up using it internally for some reason, but those changes haven't made it here yet. The problem was that you need to create the .a library file manually out of object files, because there is no way (that I know of) to have xcodebuild do that (info in the thread again).

Thanks @sjavora for your input, it makes sense that separate out the macro package. I appreciate you take time to answer my question. 🙏