rules_apple transitions

[chiragramani]

Hi,
I was exploring rules_apple examples and I see that//examples/ios/HelloWorldSwift:Sources output artifacts are not used by build actions of //examples/iOS/HelloWorldSwift. I think it's because of the transition differences. Maybe there is some configuration that I am missing on my end and hence would like to get some help in understanding this flow.

I expect that in an ideal world, if the cache has been populated for libraries, building applications should make use of the cache artifacts(libraries) and if cache is populated for application targets, then building libraries should make use of the cache artifacts as well.(as apps depend on libraries, so if they all share the same transition, this should be possible).

A.) bazel clean --expunge and then cquery on " //examples/ios/HelloWorldSwift:Sources" returns one configured target.

> bazel cquery //examples/ios/HelloWorldSwift:Sources --apple_platform_type=ios --cpu=ios_sim_arm64 --ios_minimum_os=8.0
Starting local Bazel server and connecting to it...
INFO: Analyzed target //examples/ios/HelloWorldSwift:Sources (45 packages loaded, 540 targets configured).
INFO: Found 1 target...
//examples/ios/HelloWorldSwift:Sources (d35e7c3)
INFO: Elapsed time: 6.526s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

B.) bazel cquery //examples/ios/HelloWorldSwift

>  bazel cquery //examples/iOS/HelloWorldSwift --apple_platform_type=ios --cpu=ios_sim_arm64 --ios_minimum_os=8.0     
INFO: Analyzed target //examples/ios/HelloWorldSwift:HelloWorldSwift (23 packages loaded, 770 targets configured).
INFO: Found 1 target...
//examples/ios/HelloWorldSwift:HelloWorldSwift (c6625d9)
INFO: Elapsed time: 0.351s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

C.) again bazel cquery //examples/ios/HelloWorldSwift:Sources

>  bazel cquery //examples/ios/HelloWorldSwift:Sources --apple_platform_type=ios --cpu=ios_sim_arm64 --ios_minimum_os=8.0
INFO: Analyzed target //examples/ios/HelloWorldSwift:Sources (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
//examples/ios/HelloWorldSwift:Sources (b2c5b17)
//examples/ios/HelloWorldSwift:Sources (d35e7c3)
INFO: Elapsed time: 0.061s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

Notice now we get two configured targets for the same cquery. Any idea what might be going on here?
Also, doing a bazel config shows the following:

> bazel config b2c5b17 d35e7c3
INFO: Displaying diff between configs b2c5b17 and d35e7c3
Displaying diff between configs b2c5b17 and d35e7c3
FragmentOptions com.google.devtools.build.lib.analysis.config.CoreOptions {
  affected by starlark transition: [//command_line_option:apple configuration distinguisher, //command_line_option:platforms], []
}
FragmentOptions com.google.devtools.build.lib.rules.apple.AppleCommandLineOptions {
  apple configuration distinguisher: APPLEBIN_IOS, UNKNOWN
  apple_split_cpu: sim_arm64, 
}

one has an empty apple_split_cpu but the other has sim_arm64.

[keith]

Yes your assumption that this is all due to transition differences is the case. And with the path bazel is currently going, it will always be the case for this type of library target.

I think the reason this is surprising is because with objc_library you might(*) be able get them to use the same config, until the transition is removed from that as well bazelbuild/bazel#16870

*: As we've migrated more and more things out of bazel itself, the objc_library transition implementation is here while rules_apple rules use this one, so technically those can drift between your rules version and bazel version, resulting in the same issue. This wasn't the case until some of the apple logic moved out of java and into starlark.

And with swift_library it inherited some parts of the configuration until bazelbuild/rules_swift#858, which part of the same migration (related issue bazelbuild/rules_swift#897). I still think this wouldn't have been 1:1 since it wasn't inheriting the entire transition, but I'm not sure

I think this is a weird quirk in bazel's rule designs, especially when you "know" that one specific library can only ever be built for 1 configuration. I imagine we could provide some abstractions here, like ios_swift_library if we really wanted to, and maybe we should.

I think your best short term option is to treat libraries like implementation details, tag them with tags = ["manual"] and instead expose a platform specific target such as an ios_build_test, or an ios_framework, and use that as your build target when users want to just build the library itself and not an app or test target. Since these force the same transition, they will share caches correctly.

You could attempt to mirror the transition from rules_apple and bazel and have your own ios_swift_library type rule (still think we might want to just do this), but you're definitely subject to breakages as the transition changes

[chiragramani]

Thanks @keith for sharing your thoughts and helping me in understanding this better. I am able to connect a lot of these dots now 🙌🏼 Yes, I like the idea of having something like ios_swift_library what you suggested and exposing a platform specific target also sounds like a good short term solution.

I am also curious where and why these transitions differ especially where we get a non-empty apple_split_cpu in one case whereas a valid non-empty apple_split_cpu in the other case, will debug it a bit and will share my findings with you.