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.

Sign up for GitHub

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

Jump to bottom

go/build: allow Import to ignore build constraints #15396

Open
okdave opened this issue Apr 21, 2016 · 2 comments
Open

go/build: allow Import to ignore build constraints #15396

okdave opened this issue Apr 21, 2016 · 2 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@okdave
Copy link
Contributor

okdave commented Apr 21, 2016 •
edited
Loading

There's no way at the moment to use Import or ImportDir to select all the files in package ignoring build constraints. There is the Package.IgnoredGoFiles field, but that does not extend to finding the dependencies of the ignored files, and so requires extra parsing steps.

One use case for this is in situations like App Engine: we want to select all the source files for an app, but not exclude source file that would be needed to compile a package in other/future versions of Go. So, we want to select files ignoring any go1.x tags.

/cc @dsymonds @adg
@minux
Copy link
Member

minux commented Apr 21, 2016 via email

@okdave
Copy link
Contributor Author

okdave commented Apr 21, 2016

Adding all go1.x tags isn't sufficient because then you will reject current versions: I don't want to select for just a specific future version, but rather all possible versions from now into the future.

AFAICT, the only way to achieve that with the current API would be to repeatedly invoke Import with increasing sets of tags: go1.0-go1.6; go1.0-go1.7, go1.0-go1.8, etc. Fortunately, you can use Package.IgnoredGoFiles to determine when that is necessary at all, and Package.AllTags to determine the set of version tags you need to try. But it's still very hacky.

@bradfitz bradfitz added this to the Unplanned milestone May 4, 2016
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@bradfitz @minux @okdave @seankhliao