Keith Smiley
Keith Smiley
Is the old way still supported for iOS 15+? Or do you have to use this new behavior?
I believe this was fixed by https://github.com/bazelbuild/rules_apple/pull/1191 which isn't in a release yet, can you test and see if it fixes your use case?
Hrm yea so the assumption we made in that change was that the binary can be built by bazel however it wants, respecting the CPUs flags you pass, and then...
It gets a bit more complicated with fat binaries, since I guess you have a few potential cases here: - on intel host, testing arm binary, fail - on m1...
I think if you built with `--macos_cpus=x86_64,arm64` it might, but given that would be duplicate building I'm not sure you'd want to
Will / should this have any impact on if you're linking `rust_library` targets into `cc_binary` targets instead of top level `rust_*` targets as you mention here?
I've been looking into this a bit, and it's definitely possible today by using the C++ related coverage script attribute. It feels a bit like a hack but afaict there...
Here's a super WIP version https://github.com/bazelbuild/rules_rust/pull/1324
Thanks @hlopko !
Yea I haven't addressed _lcov_merger, but am using _collect_cc_coverage in https://github.com/bazelbuild/rules_rust/pull/1324, should work fine for now