You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not entirely sure if this is rules_swift or rules_apple, but here we go.
I am trying to sort out workarounds to bazel#7944, in particular for propagating module maps from transitive dependencies of objc_librarys into their copts. While investigating this issue, I noticed that in the experimental_mixed_language_library macro from rules_apple, the objc_library that consumes an extended module map gets an additional module map created for it (I think by something in rules_swift). From a clean build of a module named PrintStream, the following module maps are created:
PrintStream.internal.objc.modulemap
PrintStream.internal.umbrella.modulemap
PrintStream.internal.umbrella.swift.modulemap
This .swift.modulemap contains all manner of headers from a given CcCompilationContext, including things that are not headers but are provided as headers due to the absence of a cc_inputs-like parameter on objc_library, such as Clang configuration files, header maps, or other module maps, and as such Clang fails to parse them. Despite this, these module maps are still propagated as -fmodule-map-file to other library targets.
My suspicion is that, unless feature loading is totally broken in swift_library (i.e. something is failing to receive the swift.no_generated_module_map setting) the issue lies somewhere in how swift_clang_module_aspect is loading objc_library module info. But beyond that, I am uncertain how to move forward. @luispadron and I made a little progress investigating, but we could use more eyes.
The text was updated successfully, but these errors were encountered:
Yes, there are a few related improvements that I need to push up to experimental_mixed_language_library. Without them, I have to continue using my highly-derivative home-cooked macro.
Not entirely sure if this is rules_swift or rules_apple, but here we go.
I am trying to sort out workarounds to bazel#7944, in particular for propagating module maps from transitive dependencies of
objc_library
s into their copts. While investigating this issue, I noticed that in theexperimental_mixed_language_library
macro from rules_apple, theobjc_library
that consumes an extended module map gets an additional module map created for it (I think by something in rules_swift). From a clean build of a module namedPrintStream
, the following module maps are created:PrintStream.internal.objc.modulemap
PrintStream.internal.umbrella.modulemap
PrintStream.internal.umbrella.swift.modulemap
This
.swift.modulemap
contains all manner of headers from a given CcCompilationContext, including things that are not headers but are provided as headers due to the absence of acc_inputs
-like parameter onobjc_library
, such as Clang configuration files, header maps, or other module maps, and as such Clang fails to parse them. Despite this, these module maps are still propagated as-fmodule-map-file
to other library targets.My suspicion is that, unless feature loading is totally broken in
swift_library
(i.e. something is failing to receive theswift.no_generated_module_map
setting) the issue lies somewhere in howswift_clang_module_aspect
is loadingobjc_library
module info. But beyond that, I am uncertain how to move forward. @luispadron and I made a little progress investigating, but we could use more eyes.The text was updated successfully, but these errors were encountered: