Showcase a fix for exposing Swift types in an Objecive-C API

[abdulowork]

This is a PoC fix for the issue described in #956

[owenv]

Thanks for the pr! Not every target will have a generated modulemap, and not every transitive dependency will build a module compatible with the current compilation, so I don't think we should attempt to inject module map flags here.

Generally speaking, the intent is that the PIF generated by swift-package-manager is supposed to include module map paths in the "imparted build properties" as needed for SwiftPM targets generating module maps. Then, swift-build is responsible for ensuring those imparted build properties are imposed on transitive dependents which build for the same platform. Based on your bug report it's possible either SwiftPM is failing to add the right path to the PIF, or the imparted properties exist but aren't propagated to dependents correctly (I haven't taken a detailed look yet). The former we'd want to fix in SwiftPM, the latter we'd likely want to fix in Swift Build at dependency resolution time instead of when we're constructing the Swift compilation task

[abdulowork]

I looked at the output of swift package dump-pif and at similar information emitted with defaults write com.apple.dt.XCBuild EnableBuildDebugging -bool YES. I see that ObjcTarget has the following in impartedBuildProperties:

"guid": "PACKAGE-TARGET:ObjcTarget",
...
"OTHER_SWIFT_FLAGS": [
  "-Xcc",
  "-fmodule-map-file=$(GENERATED_MODULEMAP_DIR)/ObjcTarget.modulemap",

And the SwiftTarget doesn't have the imparted OTHER_SWIFT_FLAGS, so the transitive Swift consumer doesn't see the generated SwiftTarget.modulemap.

That still leaves me with a couple of questions: do I understand correctly that, for general Swift -> Swift compilation dependencies, SwiftPM relies on Swift Build to produce all outputs in $(BUILT_PRODUCTS_DIR) and have them picked up by a shared swiftc -I $(BUILT_PRODUCTS_DIR) search path?

If my understanding is correct, I see another possible fix for this issue being Swift Build creating $(BUILT_PRODUCTS_DIR)/SwiftTarget directory with the module.modulemap and the SwiftTarget-Swift.h. Then, from my understanding, both clang -fmodules and swiftc can pick the necessary Clang module, and wouldn't need to rely on the imparted build settings at all.

Would such a fix be acceptable, and would it need to be implemented in Swift Build?

[abdulowork]

I think the benefit of such a solution might be that if there is no Swift Producer -> ObjC Consumer dependency, then the build system doesn't need to ask the compiler to generate the -Swift.h file, and it doesn't need to create the modulemap, but if such an edge does occur, then in the case of Swift Producer -> ObjC -> Swift Consumer the Swift Consumer will still be able to see everything due to emitted module and the header in the shared search path.

Or is this something SwiftPM must decide on ahead of time based on its knowledge about the dependency graph?

[abdulowork]

I browsed some more through the PIF files, and I see the MODULEMAP_FILE_CONTENTS, MODULEMAP_PATH, SWIFT_OBJC_INTERFACE_HEADER_DIR and SWIFT_OBJC_INTERFACE_HEADER_NAME build settings there, which I assume get encoded into PIF from here. So perhaps for the fix with the shared search path, this would still require a change in SwiftPM and not in Swift Build