Hive
GitHub issue · Open
An external package may have its own dependencies. When these are built, they should be build as the same product type as the parent. For example if my dependency Apollo is built as a dynamic framework, I would expect its dependencies ApolloAPI and ApolloUtils to also be built as dynamic frameworks.
This becomes an issue if my project has two internal libraries, say, FeedFeature and ProfileFeature that both depend on Apollo. In this case, since the nested dependencies are built as static frameworks, I see a warning because they’re being linked twice (i.e. duplicated)
In a Package.swift, we can specify the product type of a dependency like so:
#if TUIST
import ProjectDescription
let packageSettings = PackageSettings(
productTypes: [
"Apollo": .framework
]
)
#endif
let package = Package(
name: "MyProj",
dependencies: [
.package(url: "https://github.com/apollographql/apollo-ios", exact: "0.51.0")
]
)
In the Project.swift:
let project = Project(
...,
target: [
.target(name: "FeedFeature", product: .framework, dependencies: [.external(name: "Apollo")]),
.target(name: "ProfileFeature", product: .framework, dependencies: [.external(name: "Apollo")]),
]
)
When using tuist cache both my targets will have Apollo.xcframework ApolloUtils.xcframework and ApolloAPI.xcframework linked as dependencies. This is a problem since the latter two are static and these two feature frameworks will be linked into the same app.
The following warnings need attention:
· Xcframework 'ApolloUtils.xcframework' has been linked from target 'FeedFeature' and target 'ProfileFeature', it is a static product so may introduce unwanted side effects.
· Xcframework 'ApolloAPI.xcframework' has been linked from target 'FeedFeature' and target 'ProfileFeature', it is a static product so may introduce unwanted side effects.
14.5
4.23
15.4
Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.
Start a Flight and preserve its objective, outcome, and session here.
F
I would expect its dependencies ApolloAPI and ApolloUtils to also be built as dynamic frameworks.
You need to specify those as dynamic in productTypes as well.
That being said, I think I agree and it makes sense to specify to change the product type for the downstream targets, too.
Curious to get thoughts on this from @pepicrft and @danieleformichelli 👀
PD
N
M
@fortmarek Does this issue have any priority? I believe it should be a standard behaviour since you can break your project just by updating dependencies even if you setup everything correctly (a new transitive dependency is introduced in the external library of your project). Also I found out that if you integrate TCA using Tuist dependencies, mark all necessary libraries as dynamic (Tuist is satisfied, no runtime crashes), then switch to Tuist cache, it generates lots of warning in runtime and crashes. Seems like Tuist cache treats transitive dependencies differently than when compiled together with the application.
M
Also when I mark TCA’s Sharing framework as dynamic - "Sharing": .framework. I get tons of errors in unit tests due to some colliding system framework. Therefore it may not be so easy to just mark all child dependencies as dynamic. Or is there already some workaround?
dyld[21532]: symbol '_$s7Sharing16SFAirDropReceiveO7FailureO15senderCancelledyA2EmFWC' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PassKitCore.framework/PassKitCore is being set to 0xBAD4007.
dyld[21532]: symbol '_$s7Sharing16SFAirDropReceiveO7FailureO17receiverCancelledyA2EmFWC' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PassKitCore.framework/PassKitCore is being set to 0xBAD4007.
dyld[21532]: symbol '_$s7Sharing16SFAirDropReceiveO7FailureO11streamErroryA2EmFWC' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PassKitCore.framework/PassKitCore is being set to 0xBAD4007.
dyld[21532]: symbol '_$s7Sharing16SFAirDropReceiveO7FailureO10badRequestyA2EmFWC' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PassKitCore.framework/PassKitCore is being set to 0xBAD4007.
dyld[21532]: symbol '_$s7Sharing13SFAirDropSendO7FailureOMn' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PassKitCore.framework/PassKitCore is being set to 0xBAD4007.
dyld[21532]: symbol '_$s7Sharing16SFAirDropReceiveO7FailureOMn' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/PassKitCore.framework/PassKitCore is being set to 0xBAD4007.
dyld[21532]: symbol '_OBJC_CLASS_$_SFCoordinatedAlertRequest' missing from root that overrides /System/Library/PrivateFrameworks/Sharing.framework/Sharing. Use of that symbol in /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/IMDPersistence.framework/IMDPersistence is being set to 0xBAD4007.
...
B
Also when I mark TCA’s
Sharingframework as dynamic -"Sharing": .framework. I get tons of errors in unit tests due to some colliding system framework. Therefore it may not be so easy to just mark all child dependencies as dynamic. Or is there already some workaround?
Im hitting this issue as well in our TCA driven project which pulls Sharing framework
"Sharing": .framework,
P
I would expect its dependencies ApolloAPI and ApolloUtils to also be built as dynamic frameworks.
Is this what most people will expect? I’m not 100% sure. I wonder if we should instead have a mode that can be configured in PackageSettings where we take the graph, and set the product type automatically based on the graph. The thing is that depending on the configuration you are building (unknown at generation time), the thing you optimize for varies:
So perhaps this is something configurable at generation time:
tuist generate --infer-spm-linking-release
S
P