Implement go/packages API #1644
Labels
Comments
jayconrod
added
enhancement
go
tools
abhinav
pushed a commit
to uber-go/cff
that referenced
this issue
Oct 19, 2022
This commit allows CFF to get package information for dependencies from archives instead of virtualizing a gopath in the Bazel sandbox. A later diff in the stack enables this feature in the CFF Bazel rules, so this commit itself should not yield any performance gains. Currently, Bazel (v0.29.1) does not have a `go/packages` driver (bazel-contrib/rules_go#1996, bazel-contrib/rules_go#1644), and to use the `go/packages` package, it requires virtualizing a gopath, which is expensive. This stack of commits can be reverted if the gopackages driver is later implemented in Bazel. See D3490189 for a similar change for Glue. The key difference in the two diffs is that for Glue, it parses the archive file for the library itself, whereas for CFF, it parses the archive files for the library's dependencies and reads the CFF source files directly. The key reason for this is because of the "cff" build tag; since Bazel does not provide a way to pass in build tags to the go_library rule, the archive file generated for it excludes files with build tags. Consequently, parsing the archive file for the library itself yields a package without any of the actual CFF source code. The build tag is irrelevant for the Bazel system, so just removing the CFF build tag for all CFF files could have been an option. Instead, we opted to parse the dependencies' archive files to build an importer, since we wanted to keep the possibility of using CFF as a binary outside of the Bazel system. Refs T4309403 Reviewed-on: D3533489
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We need a tool that can provide data from Bazel workspaces to golang.org/x/tools/go/packages.
This will provide information about Go code in Bazel workspaces to clients of the go/packages API.
The text was updated successfully, but these errors were encountered: