The `includes` field of `objc_library` won't be propagated when `virtualize_frameworks` is enabled

[qyang-nj]

When enabling --features=apple.virtualize_frameworks, the includes field of objc_library won't be propagated to the transitive reverse apple_framework deps.

Here is the sample code.

objc_library(
    name = "Lib1",
    includes = ["Header1"],
    srcs = ["Empty.m"],
)

objc_library(
    name = "Lib2",
    includes = ["Header2"],
    srcs = ["Empty.m"],
    deps = [":Lib1"],
)

apple_framework(
    name = "Framework1",
    srcs = ["Empty.swift"],
    deps = [":Lib2"],
)

apple_framework(
    name = "Framework2",
    srcs = ["Empty.swift"],
    deps = [":Framework1"],
)

• bazel build //:Framework2 -s. Check the Swift compiler flags for Framework2 (should be a file called Framework2.swiftmodule-0.params), we see -Xcc -IHeader1 -Xcc -IHeader2.
• bazel build //:Framework2 -s --features=apple.virtualize_frameworks. Check the Swift compiler flags again, we do not see -IHearder1 or -IHeader2.

The includes field of objc_library should be propagated to all the reverse deps. This is true when the deps are objc_library, swift_library, apple_framework without virtualize_frameworks, but it's not true for apple_framework with virtualize_frameworks.

I have the sample code and repo steps here.

[jerrymarino]

include propagation is turned off in this case - it virtually supports frameworks all the way down. I imagine we'd integrate something like this to the virtual file system but it's probably an involved change - bridging other modular interfaces is something we'd want to tackle for PodToBUILD support - but hasn't had a push

This said - theres a few ways to pull it off today.

1. Can you wrap Empty.m in an apple_framework instead of using objc_library?
   or
2. If you're unable to do 1. - the other suggestion is to bridge the code from objc_library via apple_framework_packaging - something like this. I've done stuff like this to pull other objc_librarys which were bridged to a framework interface

[qyang-nj]

Thanks for the response, @jerrymarino! The problem is that the chain of #import in the header files can go nuts. It's really hard to wrap them in a modulemap without providing extra search paths. The option 1 didn't work for me, but I'll try option 2.

For more context, I'm trying to integrate FlipperKit, which has dozens of targets with c, cpp, objc and objc++ sources 😞. Not sure if anyone is successfully using it with Bazel.

[qyang-nj]

This change (#581) has fixed this problem!

[thiagohmcruz]

This change (#581) has fixed this problem!

See @jerrymarino’s comments in that PR. I was not aware of the context on this when I landed that change, it’s possible that adding this will cause perf issues but I haven’t seen any reports yet and will continue to monitor. We need both changes (1) included being propagated (2) no perf hits so if anything shows up I’d rather fix the perf issue than reverting the “includes” PR.

Please file issues here with context if you see any perf issues after start consuming this change!