Add generated_header to SwiftInfo?

[kastiglione]

We have a rule that generates a .framework bundle. These bundles can then be used via apple_static_framework_import for example.

In cases where the framework is used as a dependency of an ObjC target, the Swift generated header needs to be copied to the framework's headers directory.

We can get access to the generated header by iterating the header property of the ObjC provider and filtering for headers matching -Swift.h, but this is an ad-hoc solution. Would it be reasonable to add a generated_header property to the SwiftInfo provider, in order to make using the generated header more precise/explicit?

[kastiglione]

cc @rebello95

[allevato]

Your use case makes sense, but rather than just add another key to SwiftInfo, this got me thinking about a better way to refine the providers as a whole.

One thing I want to avoid is for SwiftInfo to become a "grab bag" of things that aren't related to Swift compilation, like the Objc provider has become (and which we're trying to fix). For example, the swiftdoc files should be moved elsewhere, since they're not compilation inputs. Since the generated header isn't needed as an input to later Swift actions, we oughtn't propagate it there either.

The same goes for the SwiftInfo.direct_* fields, which are populated but not consumed anywhere else in the rules (except for direct_swiftmodules which is used in one weird place in swift_proto_library, and that could be tweaked). Those were mainly created for IDE support (but Tulsi doesn't even use them right now), and we've thought about ways of creating "IDE info" providers that would be a common currency for rules to tell external tools about artifacts that those tool builders might find useful. I think framework bundling sounds like a similar case to that, so it might make sense to move the direct outputs into a separate provider for that purpose, and that one could include the generated header.

So this is something I think we should support, but I want to give it a little more thought (and sync up with some other rules owners) about how we might represent it before committing to anything.

[kastiglione]

Thanks for laying out the plan. Let me know if there's anything we can do to help.

[keith]

FYI if anyone is looking for a workaround for this, you can do something like what I've done here https://github.com/lyft/envoy-mobile/pull/797

[amberdixon]

we've thought about ways of creating "IDE info" providers that would be a common currency for rules to tell external tools about artifacts that those tool builders might find useful

+1 to this idea. We are also having to implement a workaround where we iterate through a headers list from an obj-c provider to obtain the path to the -Swift.h file. Would love a way of knowing beforehand about the paths to all the target's outputs, so we can use these values in our IDE projects!