cmd/go: improve the "no buildable Go source files" message

[rakyll]

Consider the following main source file:

// +build cgo

package main

func main() {

}


$ CGO_ENABLED=0 go build .
go build hello/subtests: no buildable Go source files in /Users/jbd/src/hello/subtests

The error message is very unfriendly for the new comers. It should better say "no buildable Go sources for buildtags=%q". And the user can double check if they are setting all the build tags right or will understand that the package is not supporting their build tag combination.

[quentinmit]

I suggest only changing the error message if there was a source file that was ignored due to build tags. Otherwise I think it will confuse new users to see the build tags.

[rakyll]

(It might be beyond the scope of this bug, but it might be nice to think how the go tool can report a package's build tags.)

[davecheney]

I agree, there are 7 implicit build tags applied quietly by the go tool,
go1.1, go1.2, etc. Any failure message would have to include those tags as
well as any supplied and that's going to be super confusing for newcomers,
not to mention the implicit GOOS and GOARCH tags. Especially as they cannot
see where those tags are defined or how to turn them off or on.

On Thu, 8 Sep 2016, 04:31 Quentin Smith notifications@github.com wrote:

I suggest only changing the error message if there was a source file that
was ignored due to build tags. Otherwise I think it will confuse new users
to see the build tags.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17008 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA1Bi4vGKVYP7HYup6FPZF0VuXK0Xks5qnwLjgaJpZM4J2duO
.

[ironiridis]

What about simply mentioning "(some files were excluded due to unmet build tags)"?

[rakyll]

@ironiridis, it sounds like a good and easy-to-implement idea. I will create a CL.

[gopherbot]

CL https://golang.org/cl/29113 mentions this issue.

[gopherbot]

CL https://golang.org/cl/34662 mentions this issue.

[minux]

If we fix it again, perhaps we should just make go build -x show the reason for each ignored file. $ go build -x cmd/go # file cmd/go/bootstrap.go ignored due to build tag cmd_go_bootstrap not satisfied. WORK=/tmp/go-build638479375 mkdir -p $WORK/cmd/go/_obj/ ... Not only it's clearer, it will actually help more you're debugging a build tag problem. Right now it's very hard to debug such problems (precisely because usually it's caused by a typo, and it's really really hard for people to spot such things. and this will also help if we introduce a new GOOS, and make some random x_NEWGOOS.go excluded. People who debug this issue might not know about this new GOOS)