go build ./... will produce a binary of one and only one main package is found

[tapi...@gmail.com]

I often use "go build ./..." command to check if there are compilation errors. Before ./... included 2+ main packages but now only one. Then the behavior changes, I accidentally commit and push a 10M binary to the remote repository.

Is this a intended design?

[tapi...@gmail.com]

Sorry, "of" should "if" in title.

[Brian Candler]

In short, yes this is as intended, although somewhat obscure.  The documentation is here:

"When compiling a single main package, build writes the resulting executable to an output file named after the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe') or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe'). The '.exe' suffix is added when writing a Windows executable.

When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.

The -o flag forces build to write the resulting executable or object to the named output file or directory, instead of the default behavior described in the last two paragraphs."

For me I had the problem the other way: "go build ./..." was happily building the binary when there was only one main package, but stopped working when I added a second.  The solution for me was "go build -o . ./..."

Sorry but I don't know how to make go build with a single main package discard the output.  I'd be inclined to make use of .gitignore

[tapi...@gmail.com]

Thanks for the information.

Personally, I think the behavior is hard to predict. The binary should be only produced when a single path is specified.

[Amnon]

go build ./... does build you program. I think most people would be a bit surprised if it did
something other than build.

If you don't want to build your program, but just vet that they are syntactically correct
then maybe try something like

go vet ./...

[Brian Candler]

I agree with the OP: it would be less surprising if "go build ./..." always did build and store the artefacts, and there were a separate flag to discard them.

Currently, "go build ./..." discards the build artefacts under certain conditions, see this example.

[Manlio Perillo]

Il giorno martedì 20 aprile 2021 alle 09:08:02 UTC+2 Brian Candler ha scritto:

I agree with the OP: it would be less surprising if "go build ./..." always did build and store the artefacts, and there were a separate flag to discard them.

Currently, "go build ./..." discards the build artefacts under certain conditions, see this example.

You can discard build artifacts with `go build -o /dev/null ./...`.  This is not documented and works thanks to

https://golang.org/cl/31657.

Manlio 

[Manlio Perillo]

And I notice only now that you can do `go build -o "" ./...`.

Manlio

[Brian Candler]

On Tuesday, 20 April 2021 at 20:28:56 UTC+1 manlio....@gmail.com wrote:

And I notice only now that you can do `go build -o "" ./...`.

But does that work?  See https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L374-L377

Testing with go 1.16.3 shows that it doesn't:

MacBook-Pro-4:simpletest $ ls

go.mod main.go

MacBook-Pro-4:simpletest $ go build -o "" ./...

MacBook-Pro-4:simpletest $ ls

go.mod main.go simpletest

However, -o /dev/null does work:

MacBook-Pro-4:simpletest $ rm simpletest

MacBook-Pro-4:simpletest $ go build -o /dev/null ./...

MacBook-Pro-4:simpletest $ ls

go.mod main.go

[Manlio Perillo]

Il giorno mercoledì 21 aprile 2021 alle 09:07:23 UTC+2 Brian Candler ha scritto:

On Tuesday, 20 April 2021 at 20:28:56 UTC+1 manlio....@gmail.com wrote:

And I notice only now that you can do `go build -o "" ./...`.

But does that work?  See https://github.com/golang/go/blob/master/src/cmd/go/internal/work/build.go#L374-L377

No, sorry.  I was confused by the code that set `BuildO = ""` when it is equal to `os.DevNull`.

For some reasons I was assuming the default value of `BuildO` to be the current directory ".".

 

> [...]

Manlio