Update DEFAULT_IOS_CPU for M1 arm64 simulator support

[keith]

Now that bazel supports ios_sim_arm64 we can prefer this if no other iOS
CPU is passed so that developers can build the simulator builds of their
apps / tests without having to pass a flag depending on the host.

[keith]

Depends on #13870 to actually work but I wanted to discuss separately

[keith]

My big open question here is how will platforms work for defaults like this? It would be ideally if they matched this behavior, but if not maybe we shouldn't merge this just to regress later

[keith]

So I think this change is good, but I'm not actually sure what builds read this value. It seems like this on its own does nothing for our build (but potentially that's just because we're not using many rules from bazel core) and ours is falling through to https://github.com/bazelbuild/rules_apple/blob/dd47da8154045255e2fa19ef004a518efd2304a7/apple/internal/transition_support.bzl#L43 which will have to be dealt with separately somehow

[lberki]

/cc @allevato

[allevato]

Deferring to @kaylathar for anything involving M1 support

[kaylathar]

This changes a default that could cause breakages for folks that have build fleets made up of heterogenous systems. While I think this is probably going to resolve local build problems, it is likely going to cause regressions/breaks for some folks. Given this I would be hesitant to move forward at this point, and suggest not merging this for now.

For platforms, you will actually specify a target platform or set of platforms, and the various parameters will be resolved from this, and then that will be used in toolchain selection via the constraints on what toolchains can support which parameters. E.g. if you select simulator:arm64 you would end up with something specifying a CPU constraint of arm64, with a target environment of simulator.

Insofar as how this specific PR will interact with platforms, it will depend on some details on how we move in that direction, but I imagine the new 1:* transition will set the target platform from the target platform set provided via the new option created in a62f78f - so if you fail to pass a set of target platforms, we'd fall back to the default platform, which would set this. Given this, what we change this to right now does not seem as important, as the eventual platforms solution will instead have a default target platform that ends up superseding/replacing the default CPU.

[keith]

made up of heterogenous systems

are you saying folks who already have M1 machines in their systems and want to maintain building for Intel by default? I think if folks aren't passing the archs they expect today, and are hoping it builds for a different arch than the host, while true in the past since bazel didn't support that configuration, is unexpected in general.

I would recommend folks specify the expected arch the expect to build, and then we still flip the default for the common case, which I think will be more inline with what people expect. Also since this would be able to make it in to 5.x where technically the breakage would be allowed AFAIUI?

Sounds like for platforms a similar change will make sense, and the default can be simulator + host arch, so doing this now would still pave the way to that behavior change later.

[kaylathar]

I am not against that change in principle but would require internal changes before landing as this behavior is relied on in some places.

[brentleyjones]

Hi @kaylathar can we get this in before the 5.0 cut?

[kaylathar]

This LGTM for merge.

[brentleyjones]

Thanks! @oquenchil can you import it?

[kaylathar]

@susinmotion Mind pulling this in please?

[comius]

@susinmotion @kaylathar I pulled it in.

[keith]

@comius thanks, I don't see it on master yet, is something stuck?