bazelrc: multiplatform support

[laszlocsomor]

Description of the problem / feature request:

I'd like to have some mechanism to use platform-specific flags in bazelrc files.

Feature requests: what underlying problem are you trying to solve with this feature?

Motivation is to let checked-in, project-specific bazelrc files work on all platforms. Flags dealing with paths (e.g. --output_user_root), envvars (e.g. --test_env), and external programs or shells (e.g. --workspace_status_command) are all platform-specific.

[cvcal]

We've talked about different solutions to this problem in the past, but the easiest solution is to accept multiple rc files (#4502), which will let users keep platform specific flags in the global rc while keeping project specific flags in a workspace rc file. The workspace one can be shared between different platforms.

Other solutions we've considered include checking for a "<platform>.bazelrc" filename, or making the rc file syntax more complicated so it can include some flags on some platforms and not others. Neither of these options seem to solve a problem that #4502 doesn't already address, though, and 4502 has other reasons for needing to happen.

Thoughts?

[cvcal]

The general platform issue for bazel flags is very much not solved, the solution I mentioned leaves us in basically the following state:

• host platform: goes in global bazelrc
• execution platform: if host, in global bazelrc, if remote, likely in the workspace file.
• target platform: the workspace rc file can contain --config definitions that correspond to the different configurations needed.

I realize this is not ideal, but the "right" solution is not clear to me. The fixes in the other issue will only get us out of the unusable into the "works, I guess" territory.

[ittaiz]

+1 to Chloe’s description

…

On Thu, 19 Apr 2018 at 21:03 Chloe Calvarin ***@***.***> wrote: The general platform issue for bazel flags is very much not solved, the solution I mentioned leaves us in basically the following state: - host platform: goes in global bazelrc - execution platform: if host, in global bazelrc, if remote, likely in the workspace file. - target platform: the workspace rc file can contain --config definitions that correspond to the different configurations needed. I realize this is not ideal, but the "right" solution is not clear to me. The fixes in the other issue will only get us out of the unusable into the "works, I guess" territory. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5055 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF6stjy7TekvRVqt6abeEuuYw3fqEks5tqNF1gaJpZM4TbuWV> .

[laszlocsomor]

Thoughts?

I don't really have any, you're the domain expert. :)

The fixes in the other issue will only get us out of the unusable into the "works, I guess" territory.

SGTM.

[davido]

... and external programs or shells (e.g. --workspace_status_command) are all platform-specific

This is indeed a serious problem. Gerrit Code Review has this content of tools/bazel.rc (committed in the repository):

build --workspace_status_command=./tools/workspace-status.sh

Stamping machinery shells out to cmd.exe on Windows, so that we have to provide a different script: bazel build --workspace_status_command=./tools/workspace-status.cmd .... There is currently no way to specify different option, except to overwrite it on bazel invocation.

One way to fix it is what Buck is doing in genrule by offering cmd_exe: platform specific attributes/options. So that at least for status command it could be fixed by adding platform specific option, Bazel detects the current platform and uses the rights script:

build --workspace_status_command=./tools/workspace-status.sh --workspace_status_command_exe=./tools/workspace-status.cmd

[meteorcloudy]

Other solutions we've considered include checking for a ".bazelrc" filename, or making the rc file syntax more complicated so it can include some flags on some platforms and not others. Neither of these options seem to solve a problem that #4502 doesn't already address, though,

Although #4502 is closed, we still don't have a solution to add platform specific flags without passing different build options on different platforms (such as --config=windows, --config=macos). I think we still need to come up with a solution for this.

[ZhenshengLee]

Although this issue is closed, we cannot use cutom platform specific_config setting like

test:@local_config_platform//:host --test_env=LD_LIBRARY_PATH=/gw_demo/target/xlab/sysroot/lib:$LD_LIBRARY_PATH

Correct me if I am wrong. @meteorcloudy
I think we still need to come up with a solution for this.

[meteorcloudy]

If @local_config_platform//:host always means whatever host platform you are current on, why not just test <flags> so that it always applys?

[ZhenshengLee]

If @local_config_platform//:host always means whatever host platform you are current on, why not just test <flags> so that it always applys?

Oh, I mean the actual platform specific config, is that I can do the following

build:@tools/platforms//:platform1  ...blablabla configs
build:@tools/platforms//:platform2  ...blablabla configs
test:@tools/platforms//:platform1  ...blablabla configs
test:@tools/platforms//:platform2  ...blablabla configs