I might not understand what you are intending. My understanding is that you want, given a set of .go files, know "why" they are excluded. Which, to me, means finding a configuration of build tags that would allow at least one of them to be built. A file can be built with a set of tags, if the boolean formula expressed by the build constraints <https://golang.org/cmd/go/#hdr-Build_constraints> evaluates to true. Therefore, determining why a file is excluded by a set of build tags is the boolean assignability problem.
It is trivial, given a set of build tags, to find out if a given file builds. So, it is easy to say "this file does not build given the build tags I have". But it's NP-complete, to find out what build tags must be set for a file to build. So it's hard to say "this file does not build, but it *would* if I changed the build tags to that". It's even harder to determine what the "intuitively right" answer is. For example, a package might require cgo when built on Windows/arm, but not when built on Linux/amd64. So both the answer "you need cgo" and the answer "you need to amd64" would be correct, if you are trying to build on Windows/arm and it's not obvious which is correct. Or, a more trivial example: What about a build tag like `// +build foo,!foo`? Should the report say `foo` has to be set, or that it has to not be set, or do we need additional logic to detect cases like this? Again, none of this means we can't do *something*. But without a clear, efficient algorithm and without an obviously correct answer to ambiguities, we'd first have to decide on what we'd specifically like to do :) On Mon, Mar 29, 2021 at 12:29 PM <fge...@gmail.com> wrote: > Thanks for thinking about the issue! > I should have asked for something more explicit, probably something like > this: > ; go build listconstraintexclusions > buildconstraint_1 excludes: > file1.go > file2.go > file3.go > buildconstraint_2 excludes: > file4.go > file5.go > No go files left to build. > ; > > Iiuc the complexity of creating this list is in P. > (I understand my original question was different.) > > > On 3/29/21, Axel Wagner <axel.wagner...@googlemail.com> wrote: > > In general, answering that question is NP-complete. It's the boolean > > satisfiability > > problem <https://en.wikipedia.org/wiki/Boolean_satisfiability_problem>. > It > > would be possible to implement *some* solution and maybe stop after a > > timeout or something. But even then, the answer will not be unique and > > might sometimes be less than helpful. > > > > This doesn't mean we *can't* do it, but the problem is harder than it > might > > seem. You could file an issue (after searching if someone else suggested > it > > already, of course :) ). > > > > On Mon, Mar 29, 2021 at 10:49 AM <fge...@gmail.com> wrote: > > > >> Is there some functionality to list each build constraint that is not > >> satisfied when the result of go get is "build constraints exclude all > >> Go files in ..."? > >> > >> go mod why is very helpful when module dependencies are to be explained. > >> A similar functionality would be helpful and maybe a message to refer > >> to this functionality when "build constraints exclude all Go files in > >> ..." is the conclusion. > >> > >> (For a random package I've found on pkg.go.dev it took a few confusing > >> minutes until I realized that cgo requirement is the build > >> constraint.) > >> > >> On a tangential note: would anybody else be interested to help with > >> issue https://github.com/golang/go/issues/39195 ? (Probably all build > >> constraints should be searchable.) > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "golang-nuts" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to golang-nuts+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/golang-nuts/CA%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%40mail.gmail.com > >> . > >> > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFHTz8Q1CaF3NiQo4bZYzYBr5AMmTqFCw%2Bov2tLFcLvZA%40mail.gmail.com.
