Using swift_c_module in a Swift framework about rules_swift

[chronal-xnor]

A different solution for this problem:

1. Create a swift_library target that depends on your swift_c_module target.
2. Have the swift_c_module target's module.map declare the same module name as the swift_library's module_name
3. Pass the copts = ["-import-underlying-module"] attribute to the swift_library to tell the compiler to look for a C/obj-c module with the same name

Then the C and Swift stuff both end up in the same module, and there's nothing extra to import.

This feels a little janky and rules_swift should probably do this implicitly. Either way, I feel that having a story about how C dependencies are handled is an important step towards allowing frameworks to be built with swift built under Bazel.

[chronal-xnor]

This is the hack mentioned in https://github.com/bazelbuild/rules_swift/blob/master/swift/internal/api.bzl#L765

[allevato]

Frameworks are a bit of a special case in Apple land, especially w.r.t. how they interact with modules. Frameworks really only support a single module due to the search/load logic used by the compiler (they assume that the .framework name and the .swiftmodule name match, and won't look for modules of different names inside that bundle. So the solution in your earlier comment of using -import-underlying-module is really the only way to make that work.

Even if we exclude Objective-C and Apple platforms from the equation, there are situations where it's handy to have C code in the same module as Swift code (the Swift core libraries do this in a handful of places), but it's also rare enough that it hasn't been a high priority to figure out how to handle it generally when the hack above gets most of the way there, and when rules_apple is planning on handling the case there (where it is more common, especially due to the framework issue).

Since rules_apple is going to handle the common case, I'm going to close out this issue—I'll suggest following the issue over there to get a solution that handles your use case.