-
-
Notifications
You must be signed in to change notification settings - Fork 702
Pass headers along as transitive dependencies #4298
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
Conversation
b2a1056
to
a8e2e5a
Compare
37d76da
to
931580d
Compare
fd0a8bf
to
41a5b9f
Compare
I don't want to deviate the PR discussion, just wondering, this change alone should fix |
In my testing, this change alone fixed |
@patrickmscott Friendly ping, do you have capacity to address Jay's comments? |
Yes, it just slipped off my radar. Let me see if I can address them. |
41a5b9f
to
3d7c05f
Compare
This fixes github.com/cloudflare/circl relative imports by making those headers available at compile time.
The headers from dependencies _may_ be used to produce an artifact so they should be direct dependencies.
- Collect headers and transitive headers into a depset. - Provide the headers depset to emit_compilepkg - Add a compilation target that includes headers with transitive, relative include paths.
3d7c05f
to
1474d3b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks for your patience. @fmeum any last thoughts on this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, looks good to me too!
While this repo was previously consumable as a go dependency (which is in fact how our internal monorepo consumes it), it is also useful to allow installation via Bzlmod or WORKSPACE for repos which otherwise don't require a go environment. Support for these is added here, although Bzlmod currently requires an `--override_module` flag as we aren't published to the Bazel Central Registry. The two main bits of complexity here are: 1. Making sure the requisite go module dependencies get installed. Bzlmod handles this for us, but WORKSPACE requires that we set up Gazelle to generate a macro users can call to install them. 2. Solving the patching situation with go-tree-sitter. There is an [unreleased fix](bazel-contrib/rules_go#4298) merged to rules_go which this PR uses to remove the need for patching in this repo. However, we still require the patch being available for downstream users who might not have the rules_go fix available. In the WORKSPACE setup this is handled for them by the `scala_gazelle_deps` macro, but Bzlmod users will have to add the `go_deps.module_override` manually as it is only callable from their repo's root module.
I've created a minimal reproducible example showing (now solved) CIRCL Bazel-Compilation. |
) Update rules_go to include bazel-contrib/rules_go#4298 Update gazelle to align with the version the rules_go bzlmod will bring in, and ensure the go.mod version is the same as bzlmod version. Update go to 1.21 to include the `slices` library that some of the go.mod updates depend on. Fixes #2956.
) Update rules_go to include bazel-contrib/rules_go#4298 Update gazelle to align with the version the rules_go bzlmod will bring in, and ensure the go.mod version is the same as bzlmod version. Update go to 1.21 to include the `slices` library that some of the go.mod updates depend on. Fixes #2956. --------- Co-authored-by: Douglas Thor <dougthor42@users.noreply.github.com>
This fixes github.com/cloudflare/circl relative imports by making those headers available at compile time.
What type of PR is this?
Feature
What does this PR do? Why is it needed?
Expose headers in GoArchive so that compilepkg can make them visible. This will make it possible for relative imports to find header files.
Which issues(s) does this PR fix?
Fixes #4154
Other notes for review