-
Notifications
You must be signed in to change notification settings - Fork 543
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
deps: load cc symbols from @rules_cc #1852
deps: load cc symbols from @rules_cc #1852
Conversation
I am a bit lost about the broken CI. I suspect that somehow in the workspace setup a too old rules_cc version is being used. Given |
Note, that the failing builds are using bazel |
5688034
to
c8c3561
Compare
@aignas |
Thanks for this! It's been on my cleanup list for a long time. Since this introduces a new dependency (it's not conceptually new, but will invoke the various remote-repo subsystems, so counts as new), please mention it in the changelog for completeness. I think rules_cc is largely just thin wrappers around the builtin-bazel rules still? Otherwise LGTM |
c8c3561
to
3e7e055
Compare
Work towards incompatible_stop_exporting_language_modules, see bazelbuild/bazel#19455 This elevates rules_cc from a dev dependency to a full dependency of rules_python. We need to add rules_cc to the internal deps as it has to be loaded before stardoc. Otherwise, a too old rules_cc version is used when using the legacy WORKSPACE setup
3e7e055
to
3192fb7
Compare
Yes, rules_cc are still mostly thin wrappers https://github.com/bazelbuild/rules_cc/blob/main/cc/defs.bzl#L59 |
Adds dependency on rules_cc 0.0.9 for both bzlmod and workspace
This elevates rules_cc from a dev dependency to a full dependency of rules_python.
Work towards incompatible_stop_exporting_language_modules, see bazelbuild/bazel#19455