qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-23 03:30:02 -07:00
Code Releases Activity

doc/code: drop mentions of GOPATH/pkg directory

Browse Source 
It's already half gone and later will be all gone.
It's not worth explaining in an introduction doc.

Fixes #24506
Updates #4719

Change-Id: Ie48128b3aa090d84e0e734aa45f14a4480292913
Reviewed-on: https://go-review.googlesource.com/129679
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit is contained in:
Russ Cox 2018-08-17 11:07:30 -04:00
parent 2482451f76
commit 3e0f5f934e
1 changed files with 6 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
doc/code.html
View File

@ -44,18 +44,16 @@ control repositories.
<h3 id="Workspaces">Workspaces</h3>
<p>
A workspace is a directory hierarchy with three directories at its root:
A workspace is a directory hierarchy with two directories at its root:
</p>
<ul>
<li><code>src</code> contains Go source files,
<li><code>pkg</code> contains package objects, and
<li><code>src</code> contains Go source files, and
<li><code>bin</code> contains executable commands.
</ul>
<p>
The <code>go</code> tool builds source packages and installs the resulting
binaries to the <code>pkg</code> and <code>bin</code> directories.
The <code>go</code> tool builds and installs binaries to the <code>bin</code> directory.
</p>
<p>
@ -72,10 +70,6 @@ To give you an idea of how a workspace looks in practice, here's an example:
bin/
hello # command executable
outyet # command executable
pkg/
linux_amd64/
github.com/golang/example/
stringutil.a # package object
src/
<a href="https://github.com/golang/example/">github.com/golang/example/</a>
.git/ # Git repository metadata
@ -374,9 +368,8 @@ $ <b>go build</b>
</pre>
<p>
This won't produce an output file. To do that, you must use <code>go
install</code>, which places the package object inside the <code>pkg</code>
directory of the workspace.
This won't produce an output file.
Instead it saves the compiled package in the local build cache.
</p>
<p>
@ -400,19 +393,13 @@ func main() {
</pre>
<p>
Whenever the <code>go</code> tool installs a package or binary, it also
installs whatever dependencies it has.
So when you install the <code>hello</code> program
Install the <code>hello</code> program:
</p>
<pre>
$ <b>go install github.com/user/hello</b>
</pre>
<p>
the <code>stringutil</code> package will be installed as well, automatically.
</p>
<p>
Running the new version of the program, you should see a new, reversed message:
</p>
@ -429,10 +416,6 @@ After the steps above, your workspace should look like this:
<pre>
bin/
hello # command executable
pkg/
linux_amd64/ # this will reflect your OS and architecture
github.com/user/
stringutil.a # package object
src/
github.com/user/
hello/
@ -441,22 +424,6 @@ src/
reverse.go # package source
</pre>
<p>
Note that <code>go install</code> placed the <code>stringutil.a</code> object
in a directory inside <code>pkg/linux_amd64</code> that mirrors its source
directory.
This is so that future invocations of the <code>go</code> tool can find the
package object and avoid recompiling the package unnecessarily.
The <code>linux_amd64</code> part is there to aid in cross-compilation,
and will reflect the operating system and architecture of your system.
</p>
<p>
Go command executables are statically linked; the package objects need not
be present to run Go programs.
</p>
<h3 id="PackageNames">Package names</h3>
<p>
@ -597,12 +564,6 @@ tree should now look like this:
<pre>
bin/
hello # command executable
pkg/
linux_amd64/
github.com/golang/example/
stringutil.a # package object
github.com/user/
stringutil.a # package object
src/
github.com/golang/example/
.git/ # Git repository metadata