fix: add execution platforms to more analysis tests

[fmeum]

Work towards #2850

[fmeum]

@rickeylev @aignas I need help here. I am registering the test target platform as an execution platform to ensure compatibility with the new test toolchain, but that runs into an issue I'm planning to resolve in the future by bazelbuild/bazel#26019: every py_executable has an exec dependency on a C++ toolchain through launcher_maker.

In this particular case, I could work around this by transitioning to the host platform rather than the fixed platform LINUX_X86_64. Would that be acceptable?

[rickeylev]

The launcher_maker is only needed for windows, so that dependency shouldn't be occurring for linux et al. I see it's refering to @bazel_tools//tools/launcher:launcher_maker directly, though. IIRC, bazel_tools has a select() to point that to something no-op. So it shouldn't still be requiring a C++ toolchain?

Would it help if we changed py_executable to point to an alias with select()?

alias(
    name = "launcher_maker",
    actual = select({
        "@platforms//os:windows": "@bazel_tools/tools/launcher:launcher_maker",
        "//conditions:default": "//python:none",
    })

py_executable has an optional dependency on the cc toolchain regardless, but I'm assuming that's OK.

[fmeum]

Yes, it's only needed for Windows, but with the current setup within Bazel, every OS pays the price (the exec dep on a C++ toolchain).

The selects (both the one that exists in Bazel and the one you suggest) apply after the exec transition and thus can't distinguish between a build that targets Windows and a build that doesn't. That's why I'm planning to introduce a toolchain for the launcher maker, which can match on both exec and target platform simultaneously.

However, this will require Bazel feature detection or a new BCR module for the launcher maker, so it won't help here (at least not soon).

[rickeylev]

I think I follow, I think 🙃

Transitioning to the host platform is probably ok.