Created by: robbertvanginkel
There's an undocumented #framework flavor on apple_library that in theory should generate a framework from that library. This flavor is incomplete (for example, loader paths are not set correctly), and oddly intertwined with framework embedding. There's some reference to this in the code:
https://github.com/facebook/buck/blob/3e12866d3cf233386a471f5592bd1885fb527494/src/com/facebook/buck/apple/AppleDescriptions.java#L626-L628 as well as on previous issues: https://github.com/facebook/buck/pull/818#issue-78882532
At this point the feature is undocumented, the implementation is incomplete, framework generation and embedding tightly coupled and does not allow for frameworks to be embedded correctly without making frameworks of all apple_library dependencies. I propose we remove the framework flavor as it provides little to no value and only complicates correctly fixing other features, such as prebuilt framework embedding. A commit from 2016 already proposed removing this flavor https://github.com/facebook/buck/commit/af4a756e8a982781783f8e643184b25901bf0899:
(and removing the apple library #framework flavor)
and a https://github.com/facebook/buck/pull/818#issuecomment-235945113 indicates this flavor is not used internally at facebook.
The only breakage I can see from this is that I also removed the info_plist(_substitutions) args from apple_library, now if a library does specify that after this pr buck will fail to parse. Open to suggestions if we should maybe keep it around, but as it was only ever used for when you wanted to use the framework flavor I think removing it should be okay.
I've considered if there's a possible way to decouple framework embedding and generation backward compatible way, but the only possibility I see is a new independent flavor for embedding dependent bundles (such as prebuilt frameworks). I think this will overcomplicate the code too much though, and would rather remove the framework flavor considering it does not work out of the box.
@milend @yiding