FWIW, you might be assuming that a build tag always has the form `// +build linux` or `// +build !cgo` - in which case it's indeed clear what the "correct" answer is and how to determine it. But you can't assume that build tags only take that form, you can express *any* boolean formula, using any amount of variables with them.
On Mon, Mar 29, 2021 at 12:47 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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/CAEkBMfGvyTKAMzJS7bsRmkzcMqm00FYFTD67BD2UQSfvpUpHNg%40mail.gmail.com.
