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

Listing the source files, in a module, associated with a GOOS or a GOOS/GOARCH pair #16

Open
nim-nim opened this issue Mar 29, 2019 · 4 comments

Comments

@nim-nim
Copy link

nim-nim commented Mar 29, 2019

With the advent of Go modules one can no longer ignore the side-effects of including files targeting a GOOS or a GOOS/GOARCH pair one does not need: their deps will end up in go module deps, and go will pull all the other modules those deps require, recursively.

So when you integrate software for Linux, for example, you now have to deal with a lot of windows or freebsd or whatever- support modules you have no actual need of, just because they are declared in module deps.

Therefore, we'd like to trim Go modules to only the GOOS (or alternatively GOOS+GOARCHES couples) we integrate for, to avoid this problem. Unfortunately go list and friends are especially useless, because they only know to list

  • "all source files" or
  • "all source files for this GOOS and Go build tags" + "other source files"

Which is not the correct splitting point for us. Go build tags can include other things that Go arches, and what we really need is "all source files for this GOOS, including all arches and all build tags" or "all source files for this GOOS and GOARCH, including all the combinations of build tags which are not GOARCH bits"

So if goda could provide this kind of listing, that would be useful to us.

@egonelbre
Copy link
Member

Thanks for the issues they help to make the tool better. So, keep em coming :).

@nim-nim
Copy link
Author

nim-nim commented Mar 29, 2019

Thanks for caring!

Go is currently living its own mid-life crisis: it has made easy to write a lot of code, so now there is this huge pile of code to manage and maintain. It's an opportunity for tools like goda, you chose the right time to release it.

@paralin
Copy link

paralin commented Jul 2, 2022

Did you ever find a way to do this?

@egonelbre
Copy link
Member

@paralin unfortunately no, but I also haven't put any significant time into thinking about this problem.

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

No branches or pull requests

3 participants