Add a utility to build xcframeworks #759
Conversation
ghost
requested review from
kwridan and
marciniwanicki
and removed request for
a team
|
@pepibumur your pull request is missing a changelog! |
pepicrft
force-pushed
the
xcframeworks
branch
from
e103a42
to
0a5e46a
Compare
pepicrft
force-pushed
the
xcframeworks
branch
3 times, most recently
from
fea52b5
to
b693ec5
Compare
|
(np: typo in PR title) |
pepicrft
changed the title
Sources/TuistCore/Graph/Graph.swift
Outdated
| return isDynamicLink ?? false | ||
| } | ||
| let isDynamicLink = try? frameworkMetadataProvider.linking(precompiled: frameworkNode) == .dynamic | ||
| return isDynamicLink ?? false |
There was a problem hiding this comment.
do you really want to swallow potential exceptions?
There was a problem hiding this comment.
That's a good point. Ideally we should throw an error here but we can do it as part of another PR.
| @@ -10,7 +10,7 @@ jobs: | |||
| steps: | |||
| - uses: actions/checkout@v1 | |||
| - name: GitHub Action for SwiftLint | |||
| uses: pepibumur/action-swiftlint@0d4afd006bb24e4525b5afcefd4ab5e2537193ac | |||
| uses: norio-nomura/action-swiftlint@3c67ce2e382be797d968883944140ffa0113f737 | |||
| productName: String, | ||
| xcframeworkPath: AbsolutePath) -> [String] { | ||
| var command = ["xcrun", "xcodebuild", "-create-xcframework"] | ||
| command.append(contentsOf: ["-framework", deviceArchivePath.appending(RelativePath("Products/Library/Frameworks/\(productName).framework")).pathString]) |
There was a problem hiding this comment.
Products/Library/Frameworks fixed paths are code smell to me, I guess that would break if the Xcode project configuration may define something custom here. Probably not a problem in 99% of cases but maybe you could offer a default + optional override input flag here?
There was a problem hiding this comment.
Products/Library/Frameworks fixed paths are code smell to me, I guess that would break if the Xcode project configuration may define something custom here.
Yeah, some other things might break too if Apple changes something in the API of their tools or the structure of the frameworks. To catch that we have acceptance & integration tests that should fail if that happens.
Probably not a problem in 99% of cases but maybe you could offer a default + optional override input flag here?
That would not change anything, would it? Instead of having the path defined in this line, it'd be defined a few lines above.
There was a problem hiding this comment.
I wrote that cause I thought you can provide the product path in the build settings. But I may be wrong and anyway as you say, this can be solved later 👍
pepicrft
force-pushed
the
xcframeworks
branch
from
443a839
to
c13948b
Compare
Short description 📝
In order to cache the frameworks, we need to build
.xcframeworksfirst that contain both the device and simulator's architectures.Solution 📦
This PR adds a new utility,
XCFrameworkBuilder, that given a project or workspace, and the target representation it generates an.xcframeworkin a temporary directory and returns its path.Testing strategy ✅
I've decided to use an integration test instead and runs assertions on the generated .xcframework. That way if future versions of
xcodebuildbreak the integration of this utility with the command the tests will fail and we'll catch it.