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: go/build: export an API to identify which tags are implied by a given GOOS #54738

Open
bcmills opened this issue Aug 29, 2022 · 1 comment
Labels
Milestone

Comments

@bcmills
Copy link
Member

bcmills commented Aug 29, 2022

For #51572 we added a unix build constraint that implicitly applies to all Unix-like GOOS values.

That is in addition to some GOOS chains that already existed:

  • android implies linux
  • ios implies darwin
  • illumos implies solaris

The number of such chains that already exist suggests that we may end up adding further chains in the future, and if we add new GOOS values in the future they may also imply unix, linux, or some other constraint.

Currently we have duplicated the logic for these implicit chains of constraints in at least three places: go/build, cmd/go, and cmd/dist. That suggests to me that authors of Go tools in general are likely to also need this information.

I propose that we add one or more functions to either the go/build package or the go/build/constraints package to resolve these chains. The simplest API I can think of for this would be something like:

// OSImpliedTags reports additional build tags that are implicitly satisfied
// by the given GOOS value when evaluating build constraints.
//
// The returned slice may be nil, and does not include the GOOS value itself.
func ImpliedOSTags(goos string) []string {
	var tags []string
	switch goos {
	case "android":
		tags = append(tags, "linux")
	case "ios":
		tags = append(tags, "darwin")
	case "illumos":
		tags = append(tags, "solaris")
	}
	if unixOS[goos] {
		tags = append(tags, "unix")
	}
	return tags
}
@gopherbot gopherbot added this to the Proposal milestone Aug 29, 2022
@bcmills
Copy link
Member Author

bcmills commented Aug 29, 2022

The current lack of a central API for these kinds of imported tags was a contributing factor to #54712.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

2 participants