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

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

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

bazelbuild/rules_cc#154

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

@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)

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.

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

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

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.

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?

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.

@meteorcloudy I'll look at this today

#17763

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

I believe @googlewalt is working on a roll forward.

@googlewalt how's the forward fix looking?

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

Submitted as 699e403.

Thanks!