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

go/build: document when Context.BuildTags is used/populated #27320

Closed
bradfitz opened this issue Aug 28, 2018 · 7 comments
Closed

go/build: document when Context.BuildTags is used/populated #27320

bradfitz opened this issue Aug 28, 2018 · 7 comments
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@bradfitz
Copy link
Contributor

Context.BuildTags is not set when you read go/build.Default.BuildTags.

It's only used by (*BuildTags).Import, etc.

Document that.

@bradfitz bradfitz added this to the Go1.12 milestone Aug 28, 2018
@mfrw
Copy link
Contributor

mfrw commented Aug 28, 2018

Can I take a shot on this

@gopherbot
Copy link

Change https://golang.org/cl/131975 mentions this issue: go/build: document when Context.BuildTags is used.

@ianlancetaylor
Copy link
Contributor

But why would you expect BuildTags to be set? Note that BuildTags is not ReleaseTags.

@bradfitz
Copy link
Contributor Author

bradfitz commented Aug 29, 2018

@ianlancetaylor, at Gophercon somebody wanted to get their program's build tags at runtime and their first guess was to look there. But we don't record the build tags in the binary. (Reportedly there's an existing bug where that feature request was declined, but I can't find it.)

@ianlancetaylor
Copy link
Contributor

I see. The go/build package is about building other packages. It doesn't tell you anything about your own program. Even go/build.DefaultContext is populated from GOARCH and GOOS in the environment (though naturally the default is the values used to build your program).

@bradfitz
Copy link
Contributor Author

The go/build package is about building other packages. It doesn't tell you anything about your own program.

It kinda does, though, in that people use ReleaseTags to see which version of Go it was built with.

@ianlancetaylor
Copy link
Contributor

Huh, you're right, it's a mix.

@FiloSottile FiloSottile added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 30, 2018
@golang golang locked and limited conversation to collaborators Dec 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants