Move Apple toolchain setup to apple_support

[keith]

This moves the CC toolchain for building Apple platforms besides macOS to the apple_support repo bazelbuild/apple_support#113

The default unix toolchain is now used if someone wants to build for macOS without the apple_support toolchain, but it doesn't handle as many platform specific features as the previous toolchain.

Fixes #15041

[keith]

This is failing because rules_cc references the primary file we're deleting here

[katre]

This looks reasonable. Can we migrate/update rules_cc to fix this? Ideally rules_cc wouldn't be mac-specific either.

[keith]

Yea I definitely can, the problem will be doing that in lockstep, but I guess it's ok since it's breaking either way

[keith]

bazelbuild/rules_cc#154

[keith]

I think the order of operations has to be:

1. remove from rules_cc
2. create rules_cc release, update it in bazel
3. remove here
4. merge into apple_support

[keith]

@katre ok I moved out all of the apple crosstool setup that I can, and moved it into bazelbuild/apple_support#113

one thing I'm unclear on currently is that I currently have the apple_support using local_config_cc, and falling back in the case the Apple toolchain doesn't apply. It seems ideally I would use local_config_apple_cc or something, but currently that would require we force a --crosstool_top argument that I don't think we want to. Based on https://github.com/grailbio/bazel-toolchain, this might change if we were using --incompatible_enable_cc_toolchain_resolution, but I believe that's still blocked on this detail #7260 (comment)

[katre]

The right answer is for non-toolchains users to use --crosstool_top=@rules_apple//whatever, and for toolchains users to pick it up in the WORKSPACE.

That sequencing looks right but we should confirm with @comius.

[keith]

I wonder if adding that in our transition would be enough instead of requiring that change on folks before we transition to the workspace way

[keith]

it seems like if we could change the default of apple_crosstool_top to the new toolchain when it exists users wouldn't have to know about this. we could do that always in rules_apple, but that also is used in a transition in this repo, and defaults to the default CC toolchain

[keith]

I think this is pretty close to ready, but I can't make CI green until we have a new release of rules_cc, it seems too difficult to correctly override all the tests cases for it at the moment.

[googlewalt]

We see a bunch of failures: https://buildkite.com/bazel/google-bazel-presubmit/builds/64142. We're fixing it in the internal import patch, but I want to check whether this should have been caught by bazel presubmits earlier?

[keith]

i imagine something broke since i rebased last?

[keith]

let me know if you want me to fix on this branch!

[keith]

Thanks all! @googlewalt just so I know for the future, are the files you ended up keeping libtool.sh / make_hashed_objlist.py still there because they're used in those paths internally? (since i don't see any external references)

[meteorcloudy]

https://buildkite.com/bazel/bazel-bazel/builds?branch=master&page=3
https://buildkite.com/bazel/bazel-bazel/builds/22421#0186ca61-268c-4135-b44d-f1123f11d11c

It looks like this PR is causing a lot of tests to time out in Bazel's postsubmit. @keith Can you take a look?

[meteorcloudy]

I guess we need to increase the test size of those timing out tests, e.g. https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=937

But this does indicate that there is a potential performance regression?

[googlewalt]

Thanks all! @googlewalt just so I know for the future, are the files you ended up keeping libtool.sh / make_hashed_objlist.py still there because they're used in those paths internally? (since i don't see any external references)

Yes. I suspect we should get rid of that dependency but left the cleanup for another day.

[keith]

@meteorcloudy I'll look at this today

[keith]

#17763

[meteorcloudy]

This change was rollbacked at a50cca5, @zhengwei143 can you provide more details about what was broken?

[brentleyjones]

I believe @googlewalt is working on a roll forward.

[keith]

@googlewalt how's the forward fix looking?

[googlewalt]

I just fixed one small remaining issue. Awaiting review @oquenchil.

[googlewalt]

Submitted as 699e403.

[keith]

Thanks!