Set path separator, bash path, PATH and action_env for each execution platform

[moroten]

Description of the feature request:

Bazel has builtin default paths for bash depending on operating system. They can be overridden by --shell_executable. When using remote execution towards multiple different execution platforms, e.g. both Linux and Windows in the same build, a single value for --shell_executable does not work. The same problem applies to --action_env.

The remote execution API states that

Path separators native to the operating system running on the worker SHOULD be used. If the environment_variables list contains an entry for the PATH environment variable, it SHOULD be respected. If not, the resolution process is implementation-defined.

To be able to follow the SHOULD part of the specification, I think the platform() API for defining execution platforms need to be updated to be able to set default action-env, path separator and shell executable as it is impossible for Bazel to know what platform is actually being defined.

A specific problem of today is that .bat scripts on Windows must have backslash in their paths to run, .exe works with both backslash and forward slash.

Which category does this issue belong to?

Configurability, Remote Execution

What underlying problem are you trying to solve with this feature?

Remote execution with multiple operating systems (Linux and Windows) on the remote side.

Which operating system are you running Bazel on?

Linux and Windows

What is the output of bazel info release?

release 7.3.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[tjgq]

Another case where we get in trouble with the path representation mismatch between the host and exec platforms is https://github.com/bazelbuild/bazel/issues/19208. As noted there, the hard part of fixing this issue is threading platform information to all of the places where a PathFragment is converted into a String (and probably also deferring some conversions that currently occur too early).

[moroten]

Yes, a command might want every second argument with backslash when running an action on Windows. Such part must be implemented in ctx.actions.run() which might have to get information from the resolved toolchain about how each argument should be passed. argv0 is a special case and should probably be written according to the execution platform.

[moroten]

Now when platform() has a new flags argument, maybe it will be possible to specify all these properties there.

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[fmeum]

argv[0] is formatted according to the exec OS now, although there is still a bug I'm trying to fix in https://github.com/bazelbuild/bazel/pull/28038.

Paths to the shell should be registered as toolchains, but that requires changes to Bazel for run_shell and genrule to pick them up.

Environment variables such as PATH and LC_CTYPE remain an open problem. I don't know whether flags apply to exec platforms. Do we need a separate env attribute on platform?

@katre

[katre]

I don't know whether flags apply to exec platforms.

Do you mean the platform.flag attribute? If so, then no, those are only applied for the target platform.

@gregestren and I had some discussions last year (which might have been captured in https://github.com/bazelbuild/bazel/discussions, although I can't find it quickly) about splitting the current platform rule in two: one for target platforms (to still be named platform) and one specifically for execution platforms (which would still be usable as a target platform, but also with register_execution_platforms, and which would have attributes like properties instead of exec_properties). I hoped to also tie this into a solution for Execution strategies vs platforms, as well. A new environment attribute to be set when an execution platform is in use might make some sense here, but would be a step further than just splitting the intent into a new rule type.