bazelbuild / bazelbuild/rules_cc
Provide `sysroot` with rules based toolchain, or deprecate it in bazel
- Dominant language
- Starlark
- Stars
- 247
- Forks
- 196
- PR merge metrics
- No merged PRs in 30d
Description
Currently the new rules based CC toolchain implementation never sets `builtin_sysroot` https://github.com/bazelbuild/rules_cc/blob/d74915024017250e46d95e91a3defc34174effe0/cc/toolchains/impl/toolchain_config.bzl#L69-L89 and instead just treats sysroot as any other flag https://github.com/bazelbuild/rules_cc/blob/d74915024017250e46d95e91a3defc34174effe0/cc/toolchains/args/sysroot.bzl
This diverges from the default CC toolchain behavior where the sysroot can be provided https://github.com/bazel-contrib/toolchains_llvm/blob/d557de66f23651046a6c870d44df1cb06f80910e/toolchain/cc_toolchain_config.bzl#L394 and thus other rules potentially fetch the sysroot through the public API https://github.com/bazel-contrib/rules_cuda/blob/000d119fda8ebbe02b3a94ec2ef6543ef10b8a6d/cuda/private/cuda_helper.bzl#L299
This has lead to confusion over what the "right" way to fetch the sysroot is https://github.com/bazel-contrib/rules_cuda/pull/313
I think we should either set the sysroot in the rules based toolchain, if it's provided, or deprecate the sysroot attributes in bazel, so that it's clear that they should no longer be fetched. If we deprecated the attributes in bazel I think it would be useful to provide a recommendation for how users should fetch them. One option would be requiring the user to duplicate the sysroot location knowledge and pass it to each ruleset that needs that value, for example for rules_cuda that could be `--@rules_cuda//:sysroot="the same thing you pass to the cc toolchain config"`
Contributor guide
Research direction
Start by reading cc/toolchains/impl/toolchain_config.bzl and cc/toolchains/args/sysroot.bzl, then compare their behavior with the linked toolchains_llvm and rules_cuda files. Resolve whether the rules-based toolchain should expose a provided sysroot or whether Bazel attributes should be deprecated, including a clear recommendation for consumers. Done means the chosen approach is consistently defined for rules_cuda and other users.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- build-system, compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100