Thanks, fully agree on everything. Please consider this workflow: 1. find package on pkg.go.dev (currently there is no build constraint specific information listed beside the result, cf. issue #39195) 2. get package (go get, git clone, cp etc.) 3. "build constraints exclude all Go files in ..." 4. wat? (pkg.go.dev did not "promise" this) 5. let's visit _each_file manually (or try to grep for some hints) to try to identify all failing build constraints and think about how to satisfy them or give up failing.
Please also note, if step 1 or 2 or 3 provided more information on build constraints, the failing step 3 wouldn't be surprising. Now it is and I believe some tooling support (either in step 1, 2 or 3) would be helpful. (I agree the answer to "what build tags must be set for a file to build" is NP complete.) An "explanation" like I described in my 2nd email would be very helpful and that isn't more complex than P. (If it is, please provide a hint.) Or even just the identified and relevant build constraints in CNF is most probably enough to take a look at and go like nah, I can see buildconstraintX and buildconstraintY, I can give up _quickly_ and not waste _more_ time trying to get the package to build. If you agree the workflow above is not ideal, what do you think about the "build constraint explanation" or the build constraints in CNF? On 3/29/21, Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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/CA%2Bctqrp0tL3qWWLtap1YG25GK3eDCigD3njKRYynF-RBqOnMcQ%40mail.gmail.com.
