Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: go list filtering is too coarse #30592
$ go version go version go1.11 linux/amd64
This seems like a very specific need; why not build a simple Go program to perform this with https://golang.org/pkg/go/build/?
Also, as explained in #30504, it's not clear that it would be possible for
The problem with such an approach is that the sanity checks you code end up diverging from the sanity checks go upstream builds in its own tools, and this divergence is the source of tricky bugs.
I want to load a Go module because Go is moving to modules. The sources of a module are a directory tree not a single package.
(and I know the difference between tags and arches is quite weak in Go right now but for an integrator they are not the same thing at all, one is a technical target, the other a functional one)
I personally think this is unlikely to happen in
Also note that the
Finally, it seems to me like
I still think this should be a separate tool; for one, I've never heard of anyone else with these specific needs. If you think this is a very common need, it would be helpful to give some proof or examples.
Your tool could be built on top of
That's just adding an indirection to get to the files part.
That is nice to know thanks
That's why I wrote “I know the difference between tags and arches is quite weak in Go right now but for an integrator they are not the same thing at all, one is a technical target, the other a functional one“
You can change your functional build target. You can not change the arches you build for (not if you want the result to run on the target hardware).
It's a Linux distribution need. We distribute for Linux, thus, we care only about a single system. We build lots of apps, and arches, thus we care about all build tags and arches. We reprocess upstream source files, because if they had no need of reprocessing, our users would just get them directly, without using distribution packages.
Reprocessing implies lots of filtering and selecting steps.
And, it's quite painful to report all that to Go upstream, because the generic answer is "why are you doing all those distributor things, we find no need for them". We do those things because we are a distributor and they constitute the distributor raison d'être. The go project does not do that because it's not a distributor (and violently does not want to be, hence the emphasis in shipping everything unchanged).