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

proposal: cmd/go: record build tags in build info (for debug.ReadBuildInfo) #44560

Open
rittneje opened this issue Feb 23, 2021 · 5 comments
Open
Labels
Projects
Milestone

Comments

@rittneje
Copy link

@rittneje rittneje commented Feb 23, 2021

This was asked a long time ago, and ultimately rejected, but I'm hoping it can be reconsidered. #7007

Knowing the build tags at runtime so they can be logged is very useful for debugging/troubleshooting. For example, there isn't really a way today to easily tell if a particular binary was compiled with netgo or netcgo.

To discourage abuse, and to also prevent pointlessly invalidating the build cache, I think it would be fine if the list of build tags were only able to be embedded into a global variable in the main package. For example:

package main

//go:build-tags
var BuildTags []string

func main() {
    log.Printf("built with: %s", BuildTags)
    ...
}

This is effectively equivalent to doing something like go build -tags="${BUILD_TAGS}" -ldflags "-X main.BuildTags=${BUILD_TAGS}" just without the extra manual bookkeeping.

@gopherbot gopherbot added this to the Proposal milestone Feb 23, 2021
@gopherbot gopherbot added the Proposal label Feb 23, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Feb 24, 2021
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Feb 24, 2021

Has anything changed since #7007 was declined?

@rittneje
Copy link
Author

@rittneje rittneje commented Feb 24, 2021

#7007 seemed to be asking for the ability to get the tags in an arbitrary package in order to do conditional logic. It was thus rejected because doing that was deemed hacky, and there didn't appear to be a legitimate reason to need them at runtime. But I've found that at least being able to log what they were would be very useful, similar to how we can log runtime.Version() today. I don't intend to be performing if checks with them or any such thing.

@mvdan
Copy link
Member

@mvdan mvdan commented Feb 24, 2021

Something that has changed in the recent years is the addition of https://golang.org/pkg/runtime/debug/#ReadBuildInfo. One could say that the list of build tags is part of the running binary's build information.

@rsc rsc changed the title Proposal: allow accessing build tags at runtime from main proposal: cmd/go: record build tags in build info (for debug.ReadBuildInfo) Feb 24, 2021
@rittneje
Copy link
Author

@rittneje rittneje commented Feb 25, 2021

@mvdan I don't think that runtime/debug is the best place to record the build tags, since that would cause the build cache to be invalidated for all packages that directly or indirectly import that package whenever the set of build tags changes. It is for this reason that I think embedding them directly in main is a better choice, since if I'm changing build tags, I pretty much expect at least main to change. (And the implications of a cache invalidation for the main package are lesser, since nothing should be importing it anyway.)

Unless writing them into runtime/debug can be deferred until link time? Not sure what's feasible.

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 25, 2021

@rittneje, the contents reported by runtime/debug.ReadBuildInfo are already injected more-or-less at link time by the go command. They shouldn't have any effect on cacheability for runtime/debug itself or the packages that (directly or indirectly) depend on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants