Exposes more fields in FrameworkInfo #282
Conversation
congt
force-pushed
the
cshi/framework-info
branch
from
f3d9d62 to
e202b19
Compare
Downstream targets can directly read them. A use case is to repackage a static framework into a dynamic framework.
congt
force-pushed
the
cshi/framework-info
branch
from
e202b19 to
4e0deb5
Compare
| framework_info = dep[FrameworkInfo] | ||
| fw_dep_vfsoverlays.extend(framework_info.vfsoverlay_infos) | ||
| propagated_interface_headers.append(framework_info.framework_headers) | ||
| framework_headers = depset(framework_info.headers + framework_info.modulemap + framework_info.private_headers) |
There was a problem hiding this comment.
Can you clarify why framework_info.framework_headers is not being appended anymore here? Is the new set already covering the same files?
There was a problem hiding this comment.
Yes, framework_headers originally included headers, modulemap, private_headers.
| FrameworkInfo = provider( | ||
| fields = { | ||
| "vfsoverlay_infos": "Merged VFS overlay infos, present when virtual frameworks enabled", | ||
| "framework_headers": "Headers part of the framework's public interface", |
There was a problem hiding this comment.
So this is a breaking API change right? Just checking to ensure this is intentional
There was a problem hiding this comment.
Yes, FrameworkInfo was just introduced to support vfs framework by @jerrymarino. I believe it's only used internally.
| "private_headers": "Private headers of the framework", | ||
| "modulemap": "The module map of the framework", | ||
| "swiftmodule": "The swiftmodule", | ||
| "swiftdoc": " The Swift doc", |
There was a problem hiding this comment.
what;s the relationship between swiftmoduel and swiftdoc? right now based on what i have seen it feels like swiftdoc is a child of swiftmodule... along with swiftinterface
There was a problem hiding this comment.
I guess that's just how they're packaged in a framework.
There was a problem hiding this comment.
They're all binary formats, you can read more about swift modules here: https://github.com/apple/swift/blob/main/docs/Serialization.md
(TL;DR functionally they're like headers that expose public APIs)
Also IIRC .swiftdoc files hold documentation related things like when you use "///" to document a public class and want its description to show up in the UI for who is consuming it (it could be holding more info than that but AFAIK this format is not documented)
| fields = { | ||
| "vfsoverlay_infos": "Merged VFS overlay infos, present when virtual frameworks enabled", | ||
| "framework_headers": "Headers part of the framework's public interface", | ||
| "binary": "The binary of the framework", |
There was a problem hiding this comment.
This one is returned inside of the apple binary already - any reason to replicate here?
There was a problem hiding this comment.
I want to reuse FrameworkInfo to package a dynamic framework. By adding binary and swiftmodule here, I won't need to pass around AppleBundleInfo or swiftinfo.
There was a problem hiding this comment.
What I'm saying is that today, upstream dependees of this rule are required to retrieve the swiftmodule, and binaries.
https://github.com/bazel-ios/rules_ios/blob/master/rules/framework.bzl#L497 - so it's already passed around. To access the attributes, just use framework[SwiftInfo].swiftmodule or the other existing ones
There was a problem hiding this comment.
Totally understood. I want to make FrameworkInfo self-contain from the API's perspective. Then downstream targets can only return FrameworkInfo without returning SwiftInfo or AppleBundleInfo.
| "headers": "Headers of the framework's public interface", | ||
| "private_headers": "Private headers of the framework", | ||
| "modulemap": "The module map of the framework", | ||
| "swiftmodule": "The swiftmodule", |
There was a problem hiding this comment.
These ones are in swiftinfo - any reason to put here too?
jerrymarino
left a comment
jerrymarino
left a comment
There was a problem hiding this comment.
This seems fine, I think it makes sense
Downstream targets can directly read them. A use case is to repackage a static framework into a dynamic framework.