Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 11115] ファイルの概要

このコミットは、Go言語の公式ドキュメント「How to Write Go Code」を更新し、Goプロジェクトのビルドと管理において、従来のMakefileベースのアプローチから、より現代的で標準的なgoツールを使用するアプローチへと移行する変更を反映しています。これにより、Go開発のワークフローが大幅に簡素化され、一貫性が向上しました。

コミット

doc: update "How to Write Go Code" to use the go tool

R=golang-dev, r, kevlar, rsc
CC=golang-dev
https://golang.org/cl/5534045

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/d9b82baac1f25fce52d1a392fb39711fa9462f40

元コミット内容

commit d9b82baac1f25fce52d1a392fb39711fa9462f40
Author: Andrew Gerrand <adg@golang.org>
Date:   Thu Jan 12 08:25:49 2012 +1100

    doc: update "How to Write Go Code" to use the go tool
    
    R=golang-dev, r, kevlar, rsc
    CC=golang-dev
    https://golang.org/cl/5534045
---
 doc/code.html | 289 ++++++++++++++++++++++++++--------------------------------
 1 file changed, 131 insertions(+), 158 deletions(-)

diff --git a/doc/code.html b/doc/code.html
index cdc60b0710..4737a38fd8 100644
--- a/doc/code.html
+++ b/doc/code.html
@@ -45,120 +45,89 @@ that receives a message summarizing each checkin to the Go repository.\n \n <h2 id=\"New_package\">Creating a new package</h2>\n \n+<h3>Choosing an import path</h3>\n+\n <p>\n-The source code for the package with import path\n-<code>x/y</code> is, by convention, kept in the\n-directory <code>$GOROOT/src/pkg/x/y</code>.\n+The standard packages are given short names like <code>fmt</code> and\n+<code>net/http</code> for convenience.\n+For your own projects, choose a name space that is unlikely\n+to collide with future additions to the standard library or other\n+external libraries.\n </p>\n \n-<h3>Makefile</h3>\n-\n <p>\n-It would be nice to have Go-specific tools that\n-inspect the source files to determine what to build and in\n-what order, but for now, Go uses GNU <code>make</code>.\n-Thus, the first file to create in a new package directory is\n-usually the <code>Makefile</code>.\n-The basic form used in the Go source tree\n-is illustrated by <a href=\"../src/pkg/container/vector/Makefile\"><code>src/pkg/container/vector/Makefile</code></a>:\n+For instance, if your source repository is at <code>example.com</code> \n+or <code>code.google.com/p/example</code>, you should begin your package\n+paths with that URL, as in \"<code>example.com/foo/bar</code>\" or\n+\"<code>code.google.com/p/example/foo/bar</code>\".\n+This way the <a href=\"/cmd/go/\"><code>go</code> tool</a> can automatically\n+check out and build the source code from its import path.\n </p>\n \n-<pre>\n-include ../../../Make.inc\n-\n-TARG=container/vector\n-GOFILES=\\\n-\tintvector.go\\\n-\tstringvector.go\\\n-\tvector.go\\\n-\n-include ../../../Make.pkg\n-</pre>\n-\n <p>\n-Outside the Go source tree (for personal packages), the standard form is\n+If you don\'t intend your code to be installed in this way, you should at\n+least use a unique prefix like \"<code>widgets/</code>\", as in\n+\"<code>widgets/foo/bar</code>\". A good rule is to use a prefix such as your\n+company or project name since it is unlikely to be used by another group.\n </p>\n \n-<pre>\n-include $(GOROOT)/src/Make.inc\n-\n-TARG=mypackage\n-GOFILES=\\\n-\tmy1.go\\\n-\tmy2.go\\\n \n-include $(GOROOT)/src/Make.inc\n-</pre>\n+<h3>The <code>go</code> tool and <code>GOPATH</code></h3>\n \n <p>\n-The first and last lines <code>include</code> standard definitions and rules.\n-Packages maintained in the standard Go tree use a relative path (instead of\n-<code>$(GOROOT)/src</code>) so that <code>make</code> will work correctly\n-even if <code>$(GOROOT)</code> contains spaces.\n-This makes it easy for programmers to try Go.\n+The <a href=\"/cmd/go/\"><code>go</code> tool</a> is the standard means of\n+building and installing Go libraries and programs. It is a \"zero configuration\"\n+tool; it determines how to build Go packages from their source code alone.\n </p>\n \n <p>\n-If you have not set <code>$GOROOT</code> in your environment,\n-you must run <code>gomake</code> to use this form of makefile.\n-<code>Gomake</code> also takes care to invoke GNU Make\n-even on systems where it is installed as <code>gmake</code>\n-rather than <code>make</code>.\n+To use the <code>go</code> tool effectively you must set the\n+<code>GOPATH</code> variable.\n+<code>GOPATH</code> specifies a list of paths that contain Go source code\n+and package binaries. Source code, package objects, and command binaries are\n+located inside the <code>GOPATH</code>s\' <code>src</code>, <code>pkg</code>,\n+and <code>bin</code> subdirectories respectively.\n </p>\n \n <p>\n-<code>TARG</code> is the target install path for the package,\n-the string that clients will use to import it.\n-Inside the Go tree, this string should be the same as the directory\n-in which the <code>Makefile</code> appears, with the\n-<code>$GOROOT/src/pkg/</code> prefix removed.\n-Outside the Go tree, you can use any <code>TARG</code> you\n-want that doesn\'t conflict with the standard Go package names.\n-A common convention is to use an identifying top-level name\n-to group your packages: <code>myname/tree</code>, <code>myname/filter</code>, etc.\n-Note that even if you keep your package source outside the\n-Go tree, running <code>make install</code> installs your\n-package binaries in the standard location&mdash;<code>$GOROOT/pkg</code>&mdash;to\n-make it easy to find them.\n+You should set <code>GOPATH</code> in your shell profile\n+(<code>$HOME/.bashrc</code>, <code>$HOME/.profile</code>, or equivalent).\n </p>\n \n <p>\n-<code>GOFILES</code> is a list of source files to compile to\n-create the package.  The trailing <code>\\</code> characters\n-allow the list to be split onto multiple lines\n-for easy sorting.\n+This shell session demonstrates setting <code>GOPATH</code>, creating a trivial\n+<code>widgets/foo</code> package, and building and installing the package.\n </p>\n \n-<p>\n-If you create a new package directory in the Go tree, add it to the list in\n-<code>$GOROOT/src/pkg/Makefile</code> so that it\n-is included in the standard build.  Then run:\n <pre>\n-cd $GOROOT/src/pkg\n-./deps.bash\n+$ export GOPATH=$HOME/gocode\n+$ mkdir -p $GOPATH/src/widgets/foo\n+$ cat &gt; $GOPATH/src/widgets/foo/foo.go\n+package foo\n+const String = \"Go rules!\"\n+^D\n+$ go install widgets/foo\n+$ ls $GOPATH/pkg/*/example\n+foo.a\n </pre>\n-<p>\n-to update the dependency file <code>Make.deps</code>.\n-(This happens automatically each time you run <code>all.bash</code>\n-or <code>make.bash</code>.)\n-</p>\n+\n+<p>(<code>^D</code> means to type Control-D.)</p>\n \n <p>\n-If you change the imports of an existing package,\n-you do not need to edit <code>$GOROOT/src/pkg/Makefile</code>\n-but you will still need to run <code>deps.bash</code> as above.\n+Type <code>go help gopath</code> on the command line for more information\n+about <code>GOPATH</code>.\n </p>\n \n \n <h3>Go source files</h3>\n \n <p>\n-The first statement in each of the source files listed in the <code>Makefile</code>\n-should be <code>package <i>name</i></code>, where <code><i>name</i></code>\n-is the package\'s default name for imports.\n+The first statement in a Go source file should be <code>package\n+<i>name</i></code>, where <code><i>name</i></code> is the package\'s default\n+name for imports.\n (All files in a package must use the same <code><i>name</i></code>.)\n Go\'s convention is that the package name is the last element of the\n-import path: the package imported as <code>\"crypto/rot13\"</code>\n+import path: the package imported as \"<code>crypto/rot13</code>\"\n should be named <code>rot13</code>.\n There is no requirement that package names be unique\n across all packages linked into a single binary,\n@@ -178,63 +147,81 @@ that topic.\n </p>\n \n <h2 id=\"Building_programs\">Building programs</h2>\n-<p>To build a Go program with gomake, create a Makefile alongside your program\'s\n-source files. It should be similar to the example above, but include\n-<code>Make.cmd</code> instead of <code>Make.pkg</code>:\n+\n+<p>\n+The <a href=\"/cmd/go/\"><code>go</code> tool</a> treats code belonging to\n+<code>package main</code> as an executable command, and installs the package\n+binary to the <code>GOPATH</code>\'s <code>bin</code> subdirectory.\n+</p>\n+\n+<p>\n+Building executable commands is the same as building packages.\n+Use \"<code>go install</code>\":\n+</p>\n \n <pre>\n-include $(GOROOT)/src/Make.inc\n+$ cat &gt; $GOPATH/src/widgets/bar/bar.go\n+package main\n \n-TARG=helloworld\n-GOFILES=\\\n-\thelloworld.go\\\n+import (\n+    \"fmt\"\n+    \"widgets/foo\"\n+)\n \n-include $(GOROOT)/src/Make.cmd\n+func main() {\n+    fmt.Println(foo.String)\n+}\n+^D\n+$ go install widgets/bar\n+$ $GOPATH/bin/bar\n+Go rules!\n </pre>\n \n-<p>Running <code>gomake</code> will compile <code>helloworld.go</code>\n-and produce an executable named <code>helloworld</code> in the current\n-directory.\n-</p>\n-\n <p>\n-Running <code>gomake install</code> will build <code>helloworld</code> if\n-necessary and copy it to the <code>$GOBIN</code> directory\n-(<code>$GOROOT/bin/</code> is the default).\n+Run <code>go help build</code> and <code>go help install</code> for more\n+about building and installing Go binaries.\n </p>\n \n <h2 id=\"Testing\">Testing</h2>\n \n <p>\n-Go has a lightweight test framework known as <code>gotest</code>.\n+Go has a lightweight test framework composed of the <code>go</code> tool and\n+the <code>testing</code> package.\n You write a test by creating a file with a name ending in <code>_test.go</code>\n-that contains functions named <code>TestXXX</code> with signature <code>func (t *testing.T)</code>.\n+that contains functions named <code>TestXXX</code> with signature\n+<code>func (t *testing.T)</code>.\n The test framework runs each such function;\n-if the function calls a failure function such as <code>t.Error</code> or <code>t.Fail</code>, the test is considered to have failed.\n-The <a href=\"/cmd/gotest/\">gotest command documentation</a>\n-and the <a href=\"/pkg/testing/\">testing package documentation</a> give more detail.\n+if the function calls a failure function such as <code>t.Error</code> or\n+<code>t.Fail</code>, the test is considered to have failed.\n+Run <code>go help test</code> and see the\n+<a href=\"/pkg/testing/\">testing package documentation</a> for more detail.\n </p>\n \n <p>\n-The <code>*_test.go</code> files should not be listed in the <code>Makefile</code>.\n+To run the test, run \"<code>go test</code>\":\n </p>\n \n-<p>\n-To run the test, run either <code>make test</code> or <code>gotest</code>\n-(they are equivalent).\n-To run only the tests in a single test file, for instance <code>one_test.go</code>,\n-run <code>gotest one_test.go</code>.\n-</p>\n+<pre>\n+$ cat &gt; $GOPATH/src/widgets/foo/foo_test.go\n+package foo\n \n-<p>\n-If your change affects performance, add a <code>Benchmark</code> function \n-(see the <a href=\"/cmd/gotest/\">gotest command documentation</a>)\n-and run it using <code>gotest -test.bench=.</code>.\n-</p>\n+import \"testing\"\n+\n+func TestString(t *testing.T) {\n+    const expect = \"Go rules!\"\n+    if String != expect {\n+        t.Errorf(\"String == %q, want %q\", String, expect)\n+    }\n+}\n+^D\n+$ go test widgets/foo\n+ok  \twidgets/foo\n+</pre>\n \n <p>\n-Once your new code is tested and working,\n-it\'s time to get it <a href=\"contribute.html\">reviewed and submitted</a>.\n+If your change affects performance, add a <code>Benchmark</code> function \n+(run <code>go help testfunc</code>) and run it using <code>go test\n+-test.bench=.*</code>.\n </p>\n \n <h2 id=\"pkg_example\">An example package with tests</h2>\n@@ -242,7 +229,7 @@ it\'s time to get it <a href=\"contribute.html\">reviewed and submitted</a>.\n <p>\n This example package, <code>numbers</code>, consists of the function\n <code>Double</code>, which takes an <code>int</code> and returns that value \n-multiplied by 2. It consists of three files.\n+multiplied by 2. It consists of two files.\n </p>\n \n <p>\n@@ -289,38 +276,24 @@ func TestDouble(t *testing.T) {\n </pre>\n \n <p>\n-Finally, the <code>Makefile</code>:\n-</p>\n-\n-<pre>\n-include $(GOROOT)/src/Make.inc\n-\n-TARG=numbers\n-GOFILES=\\\n-\tnumbers.go\\\n-\n-include $(GOROOT)/src/Make.pkg\n-</pre>\n-\n-<p>\n-Running <code>gomake install</code> will build and install the package to\n-the <code>$GOROOT/pkg/</code> directory (it can then be used by any\n-program on the system).\n+Running <code>go install</code> will build and install the package to\n+the <code>GOPATH</code>\'s <code>pkg</code> directory\n+(it can then be imported by any other Go program).\n </p>\n \n <p>\n-Running <code>gomake test</code> (or just running the command\n-<code>gotest</code>) will rebuild the package, including the\n+Running <code>go test</code> will rebuild the package, including the\n <code>numbers_test.go</code> file, and then run the <code>TestDouble</code>\n-function. The output \"<code>PASS</code>\" indicates that all tests passed\n+function. The output \"<code>ok</code>\" indicates that all tests passed\n successfully.  Breaking the implementation by changing the multiplier from\n <code>2</code> to <code>3</code> will allow you to see how failing tests are \n reported.\n </p>\n \n <p>\n-See the <a href=\"/cmd/gotest/\">gotest documentation</a> and the \n-<a href=\"/pkg/testing/\">testing package</a> for more detail.\n+Run <code>go help test</code>, <code>go help testfunc</code>,\n+and <code>go help testflag</code> and see the\n+<a href=\"/pkg/testing/\">testing package documentation</a> for more detail.\n </p>\n \n <h2 id=\"arch_os_specific\">Architecture- and operating system-specific code</h2>\n@@ -335,34 +308,34 @@ different operating systems.</p>\n \n <p>To compile such code, use the <code>$GOOS</code> and <code>$GOARCH</code>\n <a href=\"/doc/install.html#environment\">environment variables</a> in your\n-source file names and <code>Makefile</code>.</p>\n+source file names.</p>\n \n-<p>For example, this <code>Makefile</code> describes a package that builds on\n-different operating systems by parameterizing the file name with\n-<code>$GOOS</code>.</p>\n+<p>For example, consider the package <code>foo</code> that consists of four\n+files:</p>\n \n <pre>\n-include $(GOROOT)/src/Make.inc\n-\n-TARG=mypackage\n-GOFILES=\\\n-\tmy.go\\\n-\tmy_$(GOOS).go\\\n-\n-include $(GOROOT)/src/Make.pkg\n+foo.go\n+foo_386.go\n+foo_amd64.go\n+foo_arm.go\n </pre>\n \n-<p>The OS-specific code goes in <code>my_linux.go</code>,\n-<code>my_darwin.go</code>, and so on.</p>\n+describes a package that builds on\n+different operating systems by parameterizing the file name with\n+<code>$GOOS</code>.</p>\n+\n+<p>The general code goes in <code>foo.go</code>, while architecture-specific\n+code goes in <code>foo_386.go</code>, <code>foo_amd64.go</code>, and\n+<code>foo_arm.go</code>.</p>\n \n-<p>If you follow these conventional parameterizations, tools such as\n-<a href=\"/cmd/goinstall/\">goinstall</a> will work seamlessly with your package:\n-</p>\n+<p>If you follow these conventional parameterizations, tools such as the <a\n+href=\"/cmd/go/\"><code>go</code> tool</a> will work seamlessly with your\n+package:</p>\n \n <pre>\n-my_$(GOOS).go\n-my_$(GOARCH).go\n-my_$(GOOS)_$(GOARCH).go\n+foo_$GOOS.go\n+foo_$GOARCH.go\n+foo_$GOOS_$GOARCH.go\n </pre>\n \n-<p>The same holds for <code>.s</code> (assembly) files.</p>\n+<p>The same holds for <code>.s</code> (assembly) and <code>.c</code> files.</p>\n```

## 変更の背景

このコミットが行われた2012年1月時点では、Go言語はまだ比較的新しい言語であり、そのエコシステムは進化の途中にありました。初期のGoプロジェクトでは、C言語などの伝統的なプログラミング言語と同様に、`Makefile`を使用してソースコードのコンパイル、リンク、テストなどのビルドプロセスを管理することが一般的でした。しかし、`Makefile`は複雑になりがちで、プラットフォーム間の互換性の問題や、Go言語のシンプルな設計思想とは必ずしも合致しないという課題がありました。

Go言語の設計者たちは、よりシンプルで、設定不要（"zero configuration"）なビルドシステムを求めていました。このニーズに応える形で開発されたのが、`go`コマンドラインツールです。このツールは、Goのソースコードからパッケージのビルド方法を自動的に決定し、開発者が`Makefile`を手動で記述する手間を省くことを目的としていました。

このコミットは、Goの公式ドキュメントである「How to Write Go Code」を、この新しい`go`ツールの使用方法に準拠させるための重要な更新です。これにより、新規のGo開発者が最初から`go`ツールを使った現代的な開発ワークフローを学ぶことができるようになり、Go言語の普及と開発体験の向上に大きく貢献しました。

## 前提知識の解説

### Makefileと`make`コマンド

`Makefile`は、プログラムのコンパイルやインストールなどのタスクを自動化するためのファイルです。`make`コマンドは、この`Makefile`に記述されたルールに基づいてタスクを実行します。CやC++などのプロジェクトで広く使われており、依存関係の解決や、変更されたファイルのみを再ビルドする効率的なビルドプロセスを構築できます。しかし、`Makefile`の記述は複雑で、特にクロスプラットフォーム対応や依存関係の管理が煩雑になることがあります。

### `GOROOT`環境変数

`GOROOT`は、Go言語のSDKがインストールされているディレクトリのパスを示す環境変数です。Goのコンパイラ、標準ライブラリ、ツールなどがこのディレクトリに格納されています。初期のGo開発では、`Makefile`が`GOROOT`を参照して標準ライブラリをインクルードしたり、ビルド成果物を配置したりしていました。

### `go`ツール

`go`ツールは、Go言語の公式なコマンドラインインターフェースであり、Goプログラムの開発における中心的な役割を担います。コンパイル、パッケージ管理、テスト、ドキュメント生成、コードフォーマットなど、多岐にわたる機能を提供します。このツールは「ゼロコンフィギュレーション」を目指しており、Goのソースコードの構造からビルド方法を自動的に推論します。

### `GOPATH`環境変数

`GOPATH`は、Goのソースコード、コンパイル済みパッケージ、実行可能バイナリが配置されるワークスペースのルートディレクトリを指定する環境変数です。`GOPATH`は一つまたは複数のパスのリストとして設定でき、Goプロジェクトの標準的な配置場所を提供します。`go`ツールは、この`GOPATH`内の`src`、`pkg`、`bin`サブディレクトリを利用して、ソースコードの検索、パッケージのインストール、バイナリの配置を行います。

*   `$GOPATH/src`: Goのソースコードが配置されます。インポートパスは、この`src`ディレクトリからの相対パスに対応します。
*   `$GOPATH/pkg`: コンパイル済みのパッケージアーカイブ（`.a`ファイルなど）が配置されます。
*   `$GOPATH/bin`: `go install`コマンドでビルドされた実行可能バイナリが配置されます。

### `go install`コマンド

`go install`コマンドは、指定されたGoパッケージをコンパイルし、その結果生成されるパッケージアーカイブ（ライブラリ）または実行可能バイナリを`GOPATH`内の適切なディレクトリ（`pkg`または`bin`）にインストールします。依存関係も自動的に解決し、必要に応じてビルドします。

### `go test`コマンド

`go test`コマンドは、Goパッケージのテストを実行するためのコマンドです。Goのテストは、ファイル名が`_test.go`で終わり、`TestXXX`という形式の関数を含むGoソースファイルとして記述されます。`go test`はこれらのテストファイルを自動的に検出し、実行します。ベンチマークテストの実行機能も含まれています。

## 技術的詳細

このコミットの技術的な核心は、Go言語のビルドシステムが`Makefile`ベースの手動設定から、`go`ツールによる自動化された「ゼロコンフィギュレーション」モデルへと移行した点にあります。

1.  **ビルドプロセスの簡素化と標準化**:
    *   **旧方式 (`Makefile`)**: 開発者は各パッケージやプログラムに対して個別の`Makefile`を作成し、`include $(GOROOT)/src/Make.inc`や`include $(GOROOT)/src/Make.pkg`（または`Make.cmd`）といった共通の定義をインクルードする必要がありました。`TARG`や`GOFILES`といった変数を手動で設定し、`gomake`コマンドを使用してビルドを実行していました。これは、プロジェクトごとにビルド設定が異なったり、新しいパッケージを追加するたびに`Makefile`を更新したりする手間がありました。
    *   **新方式 (`go`ツール)**: `go`ツールは、Goのソースコードの構造（パッケージ宣言、インポートパスなど）からビルド方法を自動的に推論します。開発者は`Makefile`を記述する必要がなくなり、`go install`や`go build`といったシンプルなコマンドを実行するだけで、コンパイル、リンク、インストールが自動的に行われます。これにより、ビルドプロセスが大幅に簡素化され、Goプロジェクト全体で一貫したビルド方法が確立されました。

2.  **`GOPATH`の導入とワークスペースの概念**:
    *   **旧方式 (`GOROOT`中心)**: 開発者のコードは主に`GOROOT/src/pkg`以下に配置されるか、`Makefile`で明示的にパスを指定する必要がありました。パッケージのインポートパスも`GOROOT`からの相対パスに依存することがありました。
    *   **新方式 (`GOPATH`ワークスペース)**: `GOPATH`環境変数の導入により、Goのソースコード、コンパイル済みパッケージ、実行可能バイナリを管理するための標準的なワークスペースが定義されました。開発者は自分のプロジェクトを`$GOPATH/src`以下に配置することで、`go`ツールが自動的にソースコードを見つけ、依存関係を解決できるようになります。インポートパスは、`GOPATH/src`からの相対パスとして解決されるため、コードのポータビリティが向上しました。

3.  **テストフレームワークの統合**:
    *   **旧方式 (`gotest`コマンド)**: テストは`gotest`という独立したコマンドを使用して実行されていました。`Makefile`に`make test`として統合することも可能でしたが、基本的には別のツールでした。
    *   **新方式 (`go test`コマンド)**: `go test`コマンドが導入され、テストの実行が`go`ツールに完全に統合されました。これにより、ビルド、インストール、テストといった一連の開発ワークフローが`go`コマンド一つで完結するようになり、開発体験が向上しました。ベンチマークテストの実行も`go test -test.bench=.`のように統一されたインターフェースで行えるようになりました。

4.  **アーキテクチャ/OS固有コードの扱い**:
    *   **旧方式 (`Makefile`と環境変数)**: `Makefile`内で`$GOOS`や`$GOARCH`といった環境変数を使用して、OSやアーキテクチャ固有のソースファイルを条件付きでビルドしていました。例えば、`my_$(GOOS).go`のようなファイル名を`Makefile`に記述していました。
    *   **新方式 (ファイル命名規則)**: `go`ツールは、ファイル名に`_GOOS.go`や`_GOARCH.go`、`_GOOS_GOARCH.go`といったサフィックスが付いている場合、自動的にそのOSやアーキテクチャに特化したコードとして認識し、適切な環境でビルドします。これにより、`Makefile`を記述することなく、OS/アーキテクチャ固有のコードを管理できるようになりました。

これらの変更は、Go言語がより成熟した開発環境を提供するための重要なステップであり、Goの「シンプルさ」と「効率性」という設計哲学を具現化するものでした。

## コアとなるコードの変更箇所

このコミットで変更されたコアとなるファイルは `doc/code.html` のみです。

*   `doc/code.html`: Go言語の公式ドキュメント「How to Write Go Code」のHTMLソースファイル。

変更の概要は以下の通りです。

*   **削除された内容**:
    *   パッケージ作成時の`Makefile`の記述方法に関するセクションと、具体的な`Makefile`の例（`Make.inc`, `Make.pkg`, `Make.cmd`のインクルード、`TARG`, `GOFILES`変数の設定など）が削除されました。
    *   `gomake`コマンドの使用に関する説明が削除されました。
    *   `gotest`コマンドに関する説明が削除され、`go test`への言及に置き換えられました。
*   **追加された内容**:
    *   「The `go` tool and `GOPATH`」という新しいセクションが追加され、`GOPATH`の概念、設定方法、および`go`ツールを使ったパッケージのビルドとインストール方法が説明されています。
    *   `go install`を使ったパッケージと実行可能ファイルのビルド例が追加されました。
    *   `go test`を使ったテストの実行例と、`testing`パッケージに関する説明が追加されました。
    *   アーキテクチャ/OS固有のコードをファイル命名規則（例: `foo_GOOS.go`）で扱う方法が説明されました。

全体として、`Makefile`と`gomake`、`gotest`といった旧来のビルド・テストツールに関する記述が削除され、`go`ツールと`GOPATH`を中心とした現代的なGo開発ワークフローに関する記述に置き換えられています。

## コアとなるコードの解説

`doc/code.html`の変更点から、特に重要な部分を抜粋して解説します。

### `Makefile`関連の記述の削除

旧バージョンでは、Goパッケージのビルドに`Makefile`を使用する方法が詳細に説明されていました。例えば、以下のような`Makefile`の例が示されていました。

```html
<pre>
include ../../../Make.inc

TARG=container/vector
GOFILES=\
	intvector.go\
	stringvector.go\
	vector.go\

include ../../../Make.pkg
</pre>

このコミットでは、これらのMakefileに関する説明やコード例が完全に削除されました。これは、GoのビルドシステムがMakefileからgoツールへと移行したことを明確に示しています。

goツールとGOPATHの導入

新しく追加されたセクション「The go tool and GOPATH」では、goツールが「ゼロコンフィギュレーション」ツールであり、GOPATH環境変数の設定が必須であることが強調されています。

GOPATHの設定例と、簡単なパッケージの作成、ビルド、インストールの一連のワークフローが示されています。

<pre>
$ export GOPATH=$HOME/gocode
$ mkdir -p $GOPATH/src/widgets/foo
$ cat &gt; $GOPATH/src/widgets/foo/foo.go
package foo
const String = "Go rules!"
^D
$ go install widgets/foo
$ ls $GOPATH/pkg/*/example
foo.a
</pre>

この例では、GOPATHを$HOME/gocodeに設定し、その中にwidgets/fooというパッケージを作成しています。go install widgets/fooコマンドを実行することで、foo.goがコンパイルされ、$GOPATH/pkg以下にfoo.aというパッケージアーカイブが生成されることが示されています。これは、Goのパッケージ管理とビルドがgoツールによって自動的に行われることを示しています。

プログラムのビルド

実行可能プログラムのビルドについても、Makefileの代わりにgo installを使用する方法が説明されています。

<pre>
$ cat &gt; $GOPATH/src/widgets/bar/bar.go
package main

import (
    "fmt"
    "widgets/foo"
)

func main() {
    fmt.Println(foo.String)
}
^D
$ go install widgets/bar
$ $GOPATH/bin/bar
Go rules!
</pre>

この例では、package mainを持つbarというプログラムが、widgets/fooパッケージをインポートして使用しています。go install widgets/barを実行すると、barプログラムがコンパイルされ、$GOPATH/bin以下に実行可能バイナリが配置されます。これにより、Goの実行可能プログラムのビルドと実行が非常にシンプルになりました。

テストの実行

テストについても、従来のgotestコマンドからgo testコマンドへの移行が明確に示されています。

<pre>
$ cat &gt; $GOPATH/src/widgets/foo/foo_test.go
package foo

import "testing"

func TestString(t *testing.T) {
    const expect = "Go rules!"
    if String != expect {
        t.Errorf("String == %q, want %q", String, expect)
    }
}
^D
$ go test widgets/foo
ok  	widgets/foo
</pre>

_test.goファイルにテスト関数を記述し、go test widgets/fooを実行するだけでテストが実行されることが示されています。これにより、テストの実行もgoツールに統合され、開発ワークフローがよりスムーズになりました。

これらの変更は、Go言語のビルド、パッケージ管理、テストの各側面において、goツールとGOPATHが中心的な役割を果たすようになったことを明確に示しており、Go開発のベストプラクティスを確立する上で非常に重要なドキュメントの更新でした。

関連リンク

参考にした情報源リンク

  • コミットハッシュ: d9b82baac1f25fce52d1a392fb39711fa9462f40 のGitコミットログと差分
  • Go言語の公式ドキュメント (現在のgolang.orgのドキュメント構造に基づく推測)
  • Go言語の歴史とビルドシステムに関する一般的な知識