cmd/go: add a way to obtain a package's build ID via list -json #37281
Labels
FeatureRequest
Issues asking for a new feature that does not need a proposal.
FrozenDueToAge
help wanted
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
The toolchain computes build IDs of packages from their build input - which I believe includes a package's source code, plus the build IDs of all their dependencies.
This can be seen if one runs
go build -x
, as compiler invocations contain-buildid $BUILD_ID
. Similarly, a package's output file contains such build ID as well, so we can obtain it via these two commands:This is rather unfortunate for tools that need to look at thousands of packages at a time, though. One could use the build ID to see if a package hasn't had any changes, and thus avoid extra work. Even if we have thousands of packages, we can load them all at once with one single
go list -json
call - however, we will need one extra exec call togo tool buildid
per package, whose cost can add up quickly.I propose that we add a new field to
go list -json
to expose said build ID. For example,BuildID string
. It would be fine if populating this field required a flag like-export
.I also realise that build IDs are an internal toolchain detail, which should only matter to compiler and toolchain authors. However, there are plenty of third-party tools out there which are designed to be closely coupled with the toolchain or compiler. For example, tools designed to run via
go build -toolexec=mytool
can use build IDs to avoid work, or to produce deterministic output based on the input. This is exactly the kind of thing I do for a code obfuscator, only with lots ofgo tool buildid
calls.I also am not asking for the build ID format to be documented or stabilized. A tool shouldn't interpret the string as more than a hash if it wants to remain compatible with past and future Go versions. Or, if it really wants to parse the hash, it should only do so with very specific versions of the Go tool.
/cc @dominikh
The text was updated successfully, but these errors were encountered: