Update release packaging for Xcode 15/visionOS #8309
Conversation
tgoyne
force-pushed
the
tg/xcode-15-packaging
branch
from
1fe0538
to
ef2dfc0
Compare
|
|
||
| REALM_HIDE_SYMBOLS = NO; | ||
| REALM_OTHER_LDFLAGS_NO = ; | ||
| REALM_OTHER_LDFLAGS_YES = -Xlinker -unexported_symbols_list -Xlinker Configuration/Realm/PrivateSymbols.txt; |
There was a problem hiding this comment.
Why the need to use a file for the xlinker settings instead of declaring it here?, or this the way to do it?
There was a problem hiding this comment.
It's just incredibly unwieldily to pass multiple exclusions on the command line. This currently doesn't add the flag to the cocoapods build, but if we add that then it's nice to not have to duplicate it for that.
| @@ -5,6 +5,8 @@ x.y.z Release notes (yyyy-MM-dd) | |||
| release package. visionOS currently requires installing Realm via either | |||
| Swift Package Manager or by using a XCFramework as CocoaPods and Carthage do | |||
| not yet support it. | |||
| * Zips compatible with SPM's `.binaryTarget()` are now published as part of the | |||
There was a problem hiding this comment.
Isn't this related to this feature request?, can we link it?
| @@ -19,7 +19,7 @@ target: | |||
| - swiftpm-thread | |||
| - ios-xcode-spm | |||
| - ios-static | |||
| - ios-dynamic | |||
There was a problem hiding this comment.
On the commit , it is mentioned that removing the static target and adding the configuration added some problems, what are this problems, how did you solve them?
There was a problem hiding this comment.
It complicates the test build a bit to work with both static and dynamic linking, but it ended up being pretty minor.
| @@ -0,0 +1,177 @@ | |||
| def carthageXcodeVersion = '14.3.1' | |||
There was a problem hiding this comment.
This file will replace Jenkinsfile.releasability when this merged on the cocoa-pipeline? Or it is just another pipeline to publish?
There was a problem hiding this comment.
It's a second pipeline which publishes the things built by the first one. This one is run by the new manually-triggered Publish Cocoa Release job which will replace the cocoa-release job.
Rather than a separate target, this switches to using a different configuration for the static framework build. This eliminates most of the duplication and hacks involved, while unsurprisingly introducing a few new and different problems. There's now just a single release package rather than separate objc and swift ones. As we no longer have to deal with the backwards-compatiblity issues from bitcode, only the obj-c framework built with the most recent version of Xcode is included rather than one per Xcode version as is done with Swift. The root directory contains the dynamic xcframework that most people should be using, and the static xcframework is in the `static` subdirectory. The static framework now contains slices for all platforms rather than just iOS.
This was intended to catch places where users were trying to use a framework for the wrong platform, and XCFrameworks should render this obsolete as they no longer have to manually link the correct platform.
Carthage has had xcframework support for about two years now and the legacy fat frameworks are pretty severely broken so no one should be using them any more.
This was a legacy of the Swift 1/2/3 migrations where the compiler supported two different versions of Swift by shipping two different copies of the frontend built in different modes and we actually built for different Swift versions. These days we just build once with each Swift compiler version and don't care about the Swift version, so this logic just complicated things.
tgoyne
force-pushed
the
tg/xcode-15-packaging
branch
from
ef2dfc0
to
5bfdb1c
Compare
Most of this is cleanup of old legacy cruft that hasn't been needed for years.
Rather than a separate target, this switches to using a different configuration for the static framework build. This eliminates most of the duplication and hacks involved.
There's now just a single release package rather than separate objc and swift ones. As we no longer have to deal with the backwards-compatiblity issues from bitcode, only the obj-c framework built with the most recent version of Xcode is included rather than one per Xcode version as is done with Swift. The root directory contains the dynamic xcframework that most people should be using, and the static xcframework is in the
staticsubdirectory. The static framework now could contain slices for all platforms rather than just iOS, but in practice that was a bit over 2 GB, so it continues to only include iOS to make the download a reasonable size.RLMPlatform.h was made obsolete by XCFrameworks. Prior to those you had to manually link the correct Framework for your platform, and picking the wrong one resulted in linker errors that users didn't understand. Thankfully, that's no longer applicable.
The actual release publishing is now in a Jenkins declarative pipeline rather than being scattered over a bunch of different Jenkins jobs. A bunch of the incidental logic is now in build.sh rather than being tied specifically to Jenkins, which hopefully will help with migrating away from it.
REALM_SWIFT_VERSION was a legacy of the Swift 1/2/3 migration period where each version of the Swift compiler supported several different language versions and specifically selecting both the Xcode and Swift versions was required. Swift 4 moved away from that, and it now just complicated the logic.
Carthage has now had support for XCFrameworks for a few years and no one should be using the old fat frameworks any more, so stop publishing them.
Historically we didn't enable LTO because it made the build dramatically slower for tiny benefits, but the (relatively) new ThinLTO mostly eliminates the speed hit and meaningfully reduces the size of the binaries.