Cache with xcframeworks flag

[fortmarek]

Describe the bug

I want to use tuist cache warm --xcframeworks for my project that uses grpc-swift. Unfortunately, the aforementioned command sets xcarg with BUILD_LIBRARY_FOR_DISTRIBUTION=true but grpc-swift is not buildable with this setting and they have no plan to fix that in the near future. We also can not expect that all libraries will always be builadable with this setting.

Of course, to create xcframework, one does need to have that setting enabled - for that you can use @_implementationOnly import GRPC which ensures that nothing from GRPC will be emitted in .swiftinterface. But this is only the case when you specify BUILD_LIBRARY_FOR_DISTRIBUTION=true of the individual targets as injecting right in xcodebuild means it builds even the package dependencies with that setting.

To Reproduce

I have created a branch for this and modified workspace fixture here. To reproduce you can just check out that branch and in that fixture run tuist cache warm --xcframeworks Core

Expected behavior
I am able to warm the cache with xcframeworks even if package dependencies are not buildable for distribution if I use @_implementationOnly imports

Desktop (please complete the following information):

• OS: macOS
• Version 1.36.0

Additional context

There are two possible solutions that I can think of:

• live with some projects not being able to xcframeworks and rather add a new option in Cache.Profile, so the CI can build for iOS SDK as well
• use a similar tactic as for tuist test and generated a new project only for tuist cache warm. In this project we could enable BUILD_LIBRARY_FOR_DISTRIBUTION without modifying the user's project in unexpected ways. I believe this might be the best approach, the only issue being that this approach still does not support CocoaPods.
• Set BUILD_LIBRARY_FOR_DISTRIBUTION for the user's project generated with tuist cache warm. While it changes the project a little bit, I think it should not be a real issue for most users. This might be the easiest option to implement with the least possible issues for current projects.

I would gladly implement this once we agree on a solution.

@tuist/core 🙏

[fortmarek]

I have created a draft PR here

[thedavidharris]

-allow-internal-distribution was supposed to kind of get around this by still emitting a .swiftmodule and then anything importing the module uses the .swiftmodule over the .swiftinterface if the .swiftmodule is present and compatible with the compiler version. I'm not sure in practice how well this works though.

[danieleformichelli]

This is a problem also for OrderedCollections when imported through Dependencies.swift.
Opened an issue on their repo to see if they can support it 🤞