On Mon, Mar 29, 2021 at 2:57 PM <fge...@gmail.com> wrote:

> 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. I'm not saying the problem is not worth solving and I'm not saying
we can't do *something* to try and address it. I just don't know what,
because I don't know an answer that seems "obviously right".

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.)
>

I still don't understand how you think we should provide this explanation
without solving SAT.
For example, you write

buildconstraint_1 excludes:
file1.go
file2.go
file3.go

What is "builtconstraint_1" and how is it determined by the go tool? My
first impression was that it is supposed to be a build tag (like "cgo"),
which opens up the problems I asked - it's not clear which tag is "at
fault" or how to figure that out.

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.
>

Sure. That's certainly easy enough to do. FWIW, currently you can get an
approximation of that via

grep -R "// +build" .

After #41184 <https://github.com/golang/go/issues/41184> that would give an
even clearer result, as the build constraints are actually guaranteed to be
in DNF with at most one line per file (AIUI).

It is certainly possible to build a version of this into the Go tool for go
1.17 already. That is, we could build in a command that just recursively
looks for and parses build constraints and prints them out per-file in CNF
or DNF. Personally, I feel like I would rarely use it though, because I'd
find just a plain grep easier to remember, given that I use it daily. But
my personal feelings shouldn't deter you from proposing this :)

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/CAEkBMfFrtjRsN%2BO6z5Ed6tWB7qBDzX0xoEt06KF-wbQEaQmJYA%40mail.gmail.com.

Reply via email to