<p>Hi all,</p>
<p>Here is an example project:</p>
<pre><code>$GOPATH/src/project:
- foo
|- main.go
- bar
|- main.go
</code></pre>
<p>If I cd into foo/, run <em>go build</em>, it prodices <em>foo</em> binary in the foo/ directory. The same for bar.</p>
<p>But, if I run "go build -v ./..." in the project's root, I get the following output, and have no binaries:</p>
<pre><code>$ go build -v ./...
project/bar
project/foo
$ find .
.
./bar
./bar/main.go
./foo
./foo/main.go
</code></pre>
<p><em>go build ./...</em> for subdirs produces no binaries at all.
<em>go help packages</em> do not help to understand it.</p>
<p>So, is it designed to be like that on purpose?</p>
<p>EDIT: found in go help build:</p>
<blockquote>
<p>When the command line specifies a single main package,
build writes the resulting executable to output.
Otherwise build compiles the packages but discards the results,
serving only as a check that the packages can be built.</p>
</blockquote>
<hr/>**评论：**<br/><br/>: <pre><p>[deleted]</p></pre>divan0: <pre><p>Well, I'm aware of go install ./..., but the point is 'go build' command is a synonym for 'compile and get binary in current dir', so I do expect the same when I run with ./...</p>
<p>Now, I see in <em>go help build</em> this behavior is described, but I still wonder why it's made so. Why not build binaries for multiple packages as well on <em>go build ./...</em>?</p></pre>
