Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: search for the sysroot in compile args #313

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lukasoyen
Copy link
Contributor

@lukasoyen lukasoyen commented Jan 20, 2025

With the new cc_rules based toolchains, the sysroot on the toolchain is not set. But we can infer it from the command line args a normal compilation with that toolchain would get.

@cloudhan
Copy link
Collaborator

@lukasoyen Do you know anyway to query the info from cc_toolchain directly. This creates an unused args on each action run. And is quite wasteful... Better way should fuse it into the toolchain configuration.

@cloudhan
Copy link
Collaborator

Seems to be designed to be accessible from cc_toolchain directly

https://github.com/bazelbuild/rules_cc/blob/6be85c266b1df3a5bd38290c814d83ee643185dd/cc/private/rules_impl/cc_flags_supplier_lib.bzl#L57-L62

Then we can attach it to our cuda_info then add a corresponding feature for it.

@lukasoyen
Copy link
Contributor Author

Seems to be designed to be accessible from cc_toolchain directly

I read through that code while figuring things out. I think that is different and not meant for the rule based toolchains.

  • This is the corresponding code for the rule based toolchains. It (and the old variant) use CC_FLAGS_MAKE_VARIABLE_ACTION_NAME
  • CC_FLAGS_MAKE_VARIABLE_ACTION_NAME is not used in cc_sysroot
  • cc_toolchain_config does not set builtin_sysroot

I think the rule based toolchains are designed in a way to make the builtin_sysroot obsolete.

@lukasoyen
Copy link
Contributor Author

lukasoyen commented Jan 20, 2025

Do you know anyway to query the info from cc_toolchain directly.

As said in #313 (comment) I agree this is wasteful and slow. I don't see a reason to not put the detection into the toolchain config. The CC toolchain is an attribute already at the detection already queries the CC toolchain for the compiler binary.

I am just not sure how all that plumbing would turn out. But I am up to try if you prefer it that way.

Edit: to not put

@cloudhan
Copy link
Collaborator

Sorry for the delay. Was busy working on internal projects.

After examining the cc rules implementation https://github.com/bazelbuild/bazel/blob/a3abc625c78439a5ebf1bb09491627c802f2453d/src/main/starlark/builtins_bzl/common/cc/cc_toolchain_provider_helper.bzl#L198-L204 I think cc_toolchain.sysroot is the de facto sysroot what rules_cuda actions can rely on.

We can just ignore libc_top_label things here. See https://github.com/bazelbuild/bazel/blob/a3abc625c78439a5ebf1bb09491627c802f2453d/src/main/java/com/google/devtools/build/lib/rules/cpp/CppConfiguration.java#L796-L800 and https://bazel.build/reference/command-line-reference#flag--grte_top

Then we have a better way to implement this. I will provide you an improved PR for this issue.

Wit the new `cc_rules` based toolchains, the `sysroot` on the
toolchain is not set. But we can infer it from the command line
args a normal compilation with that toolchain would get.
@lukasoyen lukasoyen force-pushed the fix-sysroot-detection branch from 0e2bccf to ba87185 Compare February 13, 2025 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants