Keith Smiley

Yea I think there's a bug in the combination between propagating CcInfo and ObjC info leading to duplicates. If you can create a repro case I can debug futher. Note...

@olarozenfeld I think your case is a bit different, you're not pulling in rules_apple at all, just a cc_library + cc_binary, it looks to me like the core of your...

Does a newer version of bazel or rules_apple fix the issue? 🤔

Another useful case for this for `actool` would be to pass specific options if you want to produce thinned builds like `--filter-for-device-model` and `--filter-for-device-os-version`

Is that the only thing missing from making this work externally? (It seems like the rules and test runner might also need some changes?)

We have this working on our project internally, but we have a custom test runner to do so. But I can outline the gist of how it works here: 1....

Nice example. Note in general you should prefer `bazel coverage` over `bazel test`, which will also set `--collect_code_coverage` for you (and potentially flip some other things). FWIW I think we...

Yes it does, here are the docs https://docs.bazel.build/versions/master/command-line-reference.html#coverage Here's a small PR with that update https://github.com/tinder-maxwellelliott/ios-bazel-test-with-coverage/pull/5 But unrelated to that, by doing coverage correctly in the test runner instead you...

I think the changes could be entirely localized to this shell script https://github.com/bazelbuild/rules_apple/blob/master/apple/testing/default_runner/ios_test_runner.template.sh

`LCOV_MERGER` will have to be managed by users unfortunately. We currently use `--test_env= LCOV_MERGER=/usr/bin/true` to just ignore this all together. `LLVM_PROFILE_FILE` may or may not have to be passed explicitly...