Have some concept of platform that can be used from WORKSPACE and BUILD files

[kchodorow]

This has come up several times, but it is confusing to people that select doesn't work from the WORKSPACE file (nor in certain contexts). It would be nice to have something select-ish that let people switch behavior based on platform.

[jin]

Closing this, superseded by @katre's series of issues around Platforms and Toolchains.

[excitoon]

@jin What is this series of issues of @katre ? Can you mention them?
I need to access Bazel command-line flags in order to download proper dependency (based on target cpu and not host one (like in cc_configure) ). So repository_os is not enough for me...
It would be awesome if we had selects in WORKSPACE, but may be it is easier to implement repository_ctx.arguments?

[excitoon]

I can guess it's #6516 .

[jin]

@gregestren @katre do the new platforms and toolchains cover repository rules too?

[katre]

There have been a number of changes for platform and toolchain support in rules.

Currently, repository rules always execute on the host platform (ie, where Bazel itself has been invoked), and there is no support for different platforms and toolchains in repository rule implementations.

[excitoon]

@katre So basically, one cannot use buildfarm to build targeting Windows with default cc configuration logic (because the compiler is to be found on host machine) unless the environment is the same. That's sad. I wonder if there is any roadmap to cover this.

[katre]

@excitoon The autoconfigured cc toolchain is explicitly doing local auto-discovery: what compiler is installed here on this system.

For any type of remote execution, you currently need to statically define your platforms and available toolchains. We have discussed adding remote execution discovery features to Bazel, but haven't gone very far on this because it's a very complex problem.

[nlopezgi]

@excitoon ,
for remote execution we never rely on the default cc configuration logic / platforms, we override it (https://github.com/bazelbuild/bazel-toolchains/blob/master/bazelrc/bazel-0.22.0.bazelrc#L41) and instead use checked in configs (e.g. https://github.com/bazelbuild/bazel-toolchains/tree/master/configs/ubuntu16_04_clang/1.1/bazel_0.22.0/default) that we produce with a tool we have built (https://github.com/bazelbuild/bazel-toolchains/blob/master/rules/rbe_repo.bzl / https://github.com/bazelbuild/bazel-toolchains/blob/master/rules/docker_config.bzl). The tool is currently not compatible with Windows, but adding support should be feasible (though likely not trivial).

[Globegitter]

@katre I am running into an issue where I would like the users to be able to customize what nodejs to use to run in the repository rules (to run the package manager etc). They might also want to provide a path to a nodejs on their system but without a select for WORKSPACEs there is no nice way to let them pick different paths for different platforms (e.g. node.exe for windows). I could use a dict but then it is not a very nice user experience if they do not care about different platforms at all and just want to provide a single path.

[katre]

@Globegitter: The solution that you want is to define a toolchain type for nodejs, and then allow users to define different toolchains for Windows, linux, Mac, etc. Bazel will then use the platforms and toolchain information to choose the correct toolchain implementation and get the correct paths for the system where execution is happening. This will also allow Bazel to select the correct toolchain for remote execution cases, say when a user on a Mac triggers a remote build using a Linux worker (you wouldn't want the Mac binary selected then!)

You can read the docs at https://docs.bazel.build/versions/master/toolchains.html for an overview, and feel free to ask for help on the mailing list. New comments to long-closed issues are easy to miss, so the mailing list is a much better way to request help.

[Globegitter]

@katre Thank you for the response - that works for normal rules, but do repository rules have any concept of toolchains? I have actually implemented them already in rules_nodejs: bazel-contrib/rules_nodejs#827 and that is also the PR where I was running into the issue, that as far as I can see repository rules / the WORKSPACE file does not really have a notion of platforms / toolchains. The closest thing I could fin is repository_ctx.os.

[katre]

No, repository rules are not configured and so cannot take the current platform into account, so there is no way to have toolchain resolution work there.

What you can do is have a non-workspace rule for the dependency, and that rule resolves the correct toolchain to invoke to download the dependency. Then your repository rule can create the targets of that rule as needed for the required dependencies.