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

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

このコミットは、Go言語の公式ドキュメントにおける古いコンパイラ名「6g」の記述を、「gc」または「go command」に置き換える変更です。具体的には、doc/codewalk/markov.xml、doc/debugging_with_gdb.html、doc/go_faq.html の3つのドキュメントファイルが修正されています。これは、Go言語のツールチェインの進化と、それに伴うドキュメントの整合性維持を目的としたものです。

コミット

commit 2a5879d1e2f397d71097b27eda74c7867f48094a
Author: Andrew Gerrand <adg@golang.org>
Date:   Tue Mar 20 13:50:05 2012 +1100

    doc: replace mentions of 6g with gc or the go command
    
    R=golang-dev, r
    CC=golang-dev
    https://golang.org/cl/5846070

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

https://github.com/golang/go/commit/2a5879d1e2f397d71097b27eda74c7867f48094a

元コミット内容

diff --git a/doc/codewalk/markov.xml b/doc/codewalk/markov.xml
index 977c95dadb..085ead7bcf 100644
--- a/doc/codewalk/markov.xml
+++ b/doc/codewalk/markov.xml
@@ -275,16 +275,15 @@ p[len(p)-1] = suffix
 </step>
 
 <step title="Using this program" src="doc/codewalk/markov.go">
-	To use this program, first compile and link it.
-	If you are using <code>6g</code> as your compiler, the command
-	would look something like this:
+	To use this program, first build it with the
+	<a href="/cmd/go/">go</a> command:
 	<pre>
-$ 6g markov.go &amp;&amp; 6l -o markov markov.6</pre>
+$ go build markov.go</pre>
 	And then execute it while piping in some input text:
 	<pre>
-$ echo "a man a plan a canal panama" | ./markov -prefix=1
-a plan a man a plan a canal panama
-	</pre>
+$ echo "a man a plan a canal panama" \
++	| ./markov -prefix=1
+a plan a man a plan a canal panama</pre>
 	Here's a transcript of generating some text using the Go distribution's
 	README file as source material:
 	<pre>
diff --git a/doc/debugging_with_gdb.html b/doc/debugging_with_gdb.html
index 51b650b18c..84cc488db8 100644
--- a/doc/debugging_with_gdb.html
+++ b/doc/debugging_with_gdb.html
@@ -4,15 +4,15 @@
 }-->
 
 <p><i>
-This applies to the 6g toolchain. Gccgo has native gdb support. Besides this
-overview you might want to consult the
+This applies to the <code>gc</code> toolchain. Gccgo has native gdb support.
+Besides this overview you might want to consult the
 <a href="http://sourceware.org/gdb/current/onlinedocs/gdb/">GDB manual</a>.
 </i></p>
 
 <h2 id="Introduction">Introduction</h2>
 
 <p>
-When you compile and link your Go programs with the 6g/6l or 8g/8l toolchains
+When you compile and link your Go programs with the <code>gc</code> toolchain
 on Linux, Mac OSX or FreeBSD, the resulting binaries contain DWARFv3
 debugging information that recent versions (>7.1) of the GDB debugger can
 use to inspect a live process or a core dump.
diff --git a/doc/go_faq.html b/doc/go_faq.html
index c4f81c7b94..b5b7cc656d 100644
--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -187,8 +187,8 @@ document server running in a production configuration on
 Do Go programs link with C/C++ programs?</h3>
 
 <p>
-There are two Go compiler implementations, <code>6g</code> and friends, 
-generically called <code>gc</code>, and <code>gccgo</code>.\n
+There are two Go compiler implementations, <code>gc</code>
+(the <code>6g</code> program and friends) and <code>gccgo</code>.\n
 <code>Gc</code> uses a different calling convention and linker and can\n
 therefore only be linked with C programs using the same convention.\n
 There is such a C compiler but no C++ compiler. \n
@@ -994,7 +994,7 @@ Why is <code>int</code> 32 bits on 64 bit machines?</h3>
 <p>\n
 The sizes of <code>int</code> and <code>uint</code> are implementation-specific\n
 but the same as each other on a given platform.\n
-The 64 bit Go compilers (both 6g and gccgo) use a 32 bit representation for\n
+The 64 bit Go compilers (both gc and gccgo) use a 32 bit representation for\n
 <code>int</code>.  Code that relies on a particular\n
 size of value should use an explicitly sized type, like <code>int64</code>.\n
 On the other hand, floating-point scalars and complex\n
@@ -1321,7 +1321,7 @@ and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.\n
 </p>\n
 \n <p>\n-We considered writing <code>6g</code>, the original Go compiler, in Go itself but\n
+We considered writing <code>gc</code>, the original Go compiler, in Go itself but\n
 elected not to do so because of the difficulties of bootstrapping and\n
 especially of open source distribution&mdash;you'd need a Go compiler to\n
 set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to\n
@@ -1331,7 +1331,7 @@ parser are already available in the <a href="/pkg/go/"><code>go</code></a> packa\n
 </p>\n
 \n <p>\n-We also considered using LLVM for <code>6g</code> but we felt it was too large and\n
+We also considered using LLVM for <code>gc</code> but we felt it was too large and\n
 slow to meet our performance goals.\n
 </p>\n
 \n```

## 変更の背景

この変更の背景には、Go言語の初期のツールチェインの進化と、その後の標準化があります。Go言語の初期には、特定のアーキテクチャ（例: x86-64）向けのコンパイラが「6g」（Goコンパイラ）、リンカが「6l」といった命名規則で提供されていました。しかし、Go言語が成熟し、クロスプラットフォーム対応が進むにつれて、これらのアーキテクチャ固有のツール名ではなく、より汎用的な名称や統合されたコマンド体系が求められるようになりました。

「go command」（`go build`, `go run` など）の導入は、Go開発者にとってコンパイル、リンク、テスト、実行などの一連の操作を簡素化し、統一されたインターフェースを提供する画期的な変更でした。これにより、開発者は個々のコンパイラやリンカのコマンドを直接意識することなく、`go` コマンド一つで開発ワークフローを完結できるようになりました。

また、「gc」という用語は、Go言語の公式コンパイラスイート全体を指す一般的な名称として定着しました。これは、特定のアーキテクチャに依存しない、Goチームが開発・メンテナンスしている主要なコンパイラ実装を意味します。

このコミットは、このようなツールチェインの進化と標準化に伴い、古いドキュメントが新しい現実を反映するように更新されたものです。これにより、ドキュメントの正確性が向上し、Go言語を学ぶ新規開発者が混乱することなく、最新のツールチェインを理解できるようになります。

## 前提知識の解説

このコミットを理解するためには、Go言語の初期のツールチェインと、現在の「go command」の役割について理解しておく必要があります。

### Go言語の初期のツールチェイン（6g, 6l, 8g, 8lなど）

Go言語の初期バージョンでは、コンパイラとリンカはターゲットアーキテクチャに基づいて命名されていました。

*   **6g**: x86-64（64ビットIntel/AMD）アーキテクチャ向けのGoコンパイラ。
*   **6l**: x86-64アーキテクチャ向けのGoリンカ。
*   **8g**: x86（32ビットIntel/AMD）アーキテクチャ向けのGoコンパイラ。
*   **8l**: x86アーキテクチャ向けのGoリンカ。
*   **5g**: ARMアーキテクチャ向けのGoコンパイラ。
*   **5l**: ARMアーキテクチャ向けのGoリンカ。

これらのツールは、それぞれ特定のタスク（コンパイル、リンク）と特定のアーキテクチャを担当していました。開発者は、プログラムをビルドするために、これらのコマンドを直接呼び出す必要がありました。例えば、`6g program.go && 6l -o program program.6` のように、コンパイルとリンクのステップを明示的に実行していました。

### gc (Go Compiler Suite)

「gc」は、Go言語の公式コンパイラスイート全体を指す総称です。これは、Goチームによって開発され、Go言語の標準実装として提供されているコンパイラ、アセンブラ、リンカなどのツールの集合体を意味します。初期の「6g」や「8g」といったアーキテクチャ固有のコンパイラも、この「gc」スイートの一部でした。現在では、特定のアーキテクチャ名を冠したコマンドを直接使うことは稀で、通常は「go command」を通じて「gc」スイートのツールが間接的に利用されます。

### go command (`go build`, `go run`など)

「go command」は、Go言語のビルドシステムとワークフローを管理するための統合コマンドラインツールです。Go 1.0のリリースとともに導入され、Go開発の体験を劇的に改善しました。

`go command` は、以下のような多くのサブコマンドを提供します。

*   **`go build`**: ソースコードをコンパイルして実行可能ファイルを生成します。内部的には適切な「gc」コンパイラとリンカを呼び出します。
*   **`go run`**: ソースコードをコンパイルし、すぐに実行します。一時的な実行可能ファイルを生成し、実行後に削除します。
*   **`go test`**: テストを実行します。
*   **`go get`**: 外部パッケージをダウンロードしてインストールします。
*   **`go fmt`**: ソースコードをGoの標準フォーマットに整形します。
*   **`go install`**: パッケージをコンパイルし、`GOPATH/bin` または `GOBIN` にインストールします。

`go command` の導入により、開発者はコンパイラやリンカの具体的なコマンドやオプションを覚える必要がなくなり、より高レベルな抽象化されたコマンドでGoプログラムを扱えるようになりました。これは、Go言語の使いやすさと生産性を大きく向上させました。

## 技術的詳細

このコミットは、Go言語のドキュメントにおける用語の現代化と正確性の向上を目的としています。技術的な観点から見ると、これは単なる文字列の置換以上の意味を持ちます。

1.  **ツールチェインの抽象化**:
    *   以前のドキュメントでは、`6g` や `6l` といった具体的なコンパイラ・リンカのコマンドを直接使用する例が示されていました。これは、Go言語の初期段階では一般的でしたが、`go command` の導入により、これらの低レベルなコマンドを直接操作する必要がなくなりました。
    *   この変更により、ドキュメントは `go build` のような `go command` のサブコマンドを使用するように更新され、Go開発の現代的なベストプラクティスを反映しています。これにより、ユーザーはGoプログラムのビルドと実行がよりシンプルになったことを理解できます。

2.  **コンパイラ実装の総称化**:
    *   `6g` は特定のアーキテクチャ（x86-64）向けのコンパイラを指していましたが、`gc` はGo言語の公式コンパイラスイート全体を指す総称です。この変更は、Goコンパイラが単一のアーキテクチャに限定されるものではなく、複数のアーキテクチャをサポートする包括的なシステムであることを明確にします。
    *   特に `doc/go_faq.html` では、「Goには `6g` とその仲間たち、総称して `gc` と呼ばれるものと `gccgo` の2つのコンパイラ実装がある」という記述が、「Goには `gc` ( `6g` プログラムとその仲間たち) と `gccgo` の2つのコンパイラ実装がある」と修正されています。これは、`6g` が `gc` スイートの一部であるという関係性をより正確に表現しています。

3.  **ドキュメントの整合性と将来性**:
    *   古いツール名がドキュメントに残っていると、新規ユーザーが混乱したり、誤った情報に基づいて開発を進めたりする可能性があります。この変更は、ドキュメントが常に最新のツールチェインと用語を反映するようにするための継続的な取り組みの一部です。
    *   `go command` はGo言語の安定したインターフェースであり、将来のGoのバージョンアップにおいても、個々のコンパイラやリンカの実装が変更されても、`go command` のインターフェースは維持される可能性が高いです。これにより、ドキュメントの陳腐化を防ぎ、長期的なメンテナンス性を向上させます。

このコミットは、Go言語のツールチェインが成熟し、よりユーザーフレンドリーで抽象化されたインターフェースへと移行した歴史的な節目をドキュメントに反映させる重要なステップと言えます。

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

### `doc/codewalk/markov.xml`

このファイルは、Goのコードウォーク（チュートリアル）の一部で、Markov連鎖プログラムの使用方法を説明しています。

```diff
--- a/doc/codewalk/markov.xml
+++ b/doc/codewalk/markov.xml
@@ -275,16 +275,15 @@ p[len(p)-1] = suffix
 </step>
 
 <step title="Using this program" src="doc/codewalk/markov.go">
-	To use this program, first compile and link it.
-	If you are using <code>6g</code> as your compiler, the command
-	would look something like this:
+	To use this program, first build it with the
+	<a href="/cmd/go/">go</a> command:
 	<pre>
-$ 6g markov.go &amp;&amp; 6l -o markov markov.6</pre>
+$ go build markov.go</pre>
 	And then execute it while piping in some input text:
 	<pre>
-$ echo "a man a plan a canal panama" | ./markov -prefix=1
-a plan a man a plan a canal panama
-	</pre>
+$ echo "a man a plan a canal panama" \
++	| ./markov -prefix=1
+a plan a man a plan a canal panama</pre>
 	Here's a transcript of generating some text using the Go distribution's
 	README file as source material:
 	<pre>

doc/debugging_with_gdb.html

このファイルは、GDBを使用したGoプログラムのデバッグ方法に関するドキュメントです。

--- a/doc/debugging_with_gdb.html
+++ b/doc/debugging_with_gdb.html
@@ -4,15 +4,15 @@
 }-->
 
 <p><i>
-This applies to the 6g toolchain. Gccgo has native gdb support. Besides this
-overview you might want to consult the
+This applies to the <code>gc</code> toolchain. Gccgo has native gdb support.
+Besides this overview you might want to consult the
 <a href="http://sourceware.org/gdb/current/onlinedocs/gdb/">GDB manual</a>.
 </i></p>
 
 <h2 id="Introduction">Introduction</h2>
 
 <p>
-When you compile and link your Go programs with the 6g/6l or 8g/8l toolchains
+When you compile and link your Go programs with the <code>gc</code> toolchain
 on Linux, Mac OSX or FreeBSD, the resulting binaries contain DWARFv3
 debugging information that recent versions (>7.1) of the GDB debugger can
 use to inspect a live process or a core dump.

doc/go_faq.html

このファイルは、Go言語に関するよくある質問（FAQ）をまとめたドキュメントです。

--- a/doc/go_faq.html
+++ b/doc/go_faq.html
@@ -187,8 +187,8 @@ document server running in a production configuration on
 Do Go programs link with C/C++ programs?</h3>
 
 <p>
-There are two Go compiler implementations, <code>6g</code> and friends, 
-generically called <code>gc</code>, and <code>gccgo</code>.\n
+There are two Go compiler implementations, <code>gc</code>
+(the <code>6g</code> program and friends) and <code>gccgo</code>.\n
 <code>Gc</code> uses a different calling convention and linker and can\n
 therefore only be linked with C programs using the same convention.\n
 There is such a C compiler but no C++ compiler. \n
@@ -994,7 +994,7 @@ Why is <code>int</code> 32 bits on 64 bit machines?</h3>
 <p>\n
 The sizes of <code>int</code> and <code>uint</code> are implementation-specific\n
 but the same as each other on a given platform.\n
-The 64 bit Go compilers (both 6g and gccgo) use a 32 bit representation for\n
+The 64 bit Go compilers (both gc and gccgo) use a 32 bit representation for\n
 <code>int</code>.  Code that relies on a particular\n
 size of value should use an explicitly sized type, like <code>int64</code>.\n
 On the other hand, floating-point scalars and complex\n
@@ -1321,7 +1321,7 @@ and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.\n
 </p>\n
 \n <p>\n-We considered writing <code>6g</code>, the original Go compiler, in Go itself but\n
+We considered writing <code>gc</code>, the original Go compiler, in Go itself but\n
 elected not to do so because of the difficulties of bootstrapping and\n
 especially of open source distribution&mdash;you'd need a Go compiler to\n
 set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to\n
@@ -1331,7 +1331,7 @@ parser are already available in the <a href="/pkg/go/"><code>go</code></a> packa\n
 </p>\n
 \n <p>\n-We also considered using LLVM for <code>6g</code> but we felt it was too large and\n
+We also considered using LLVM for <code>gc</code> but we felt it was too large and\n
 slow to meet our performance goals.\n
 </p>\n
 \n```

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

### `doc/codewalk/markov.xml` の変更

*   **変更前**: プログラムのコンパイルとリンクに `6g markov.go && 6l -o markov markov.6` というコマンドを使用するよう指示していました。これは、Go言語の初期のビルドプロセスを反映しています。
*   **変更後**: `go build markov.go` という `go command` を使用するよう変更されました。これにより、Goプログラムのビルドがよりシンプルで統一された方法で行えるようになったことを示しています。また、`go` コマンドへのリンクも追加され、詳細情報へのアクセスが容易になっています。
*   **`echo` コマンドの改行**: `echo` コマンドの例で、パイプと実行ファイルへのパスが改行されて表示されるように修正されています。これは、表示上の整形であり、機能的な変更ではありません。

### `doc/debugging_with_gdb.html` の変更

*   **変更前**: GDBデバッグの適用範囲を「6g toolchain」としていました。
*   **変更後**: 適用範囲を「`gc` toolchain」に変更しました。これは、GDBデバッグが特定のアーキテクチャ向けコンパイラ（6g）だけでなく、Goの主要なコンパイラスイート全体（gc）に適用されることを明確にしています。また、`6g/6l` や `8g/8l` といった具体的なツールチェインの記述も `gc` ツールチェインに統一されています。

### `doc/go_faq.html` の変更

*   **コンパイラ実装の記述**:
    *   **変更前**: 「Goには `6g` とその仲間たち、総称して `gc` と呼ばれるものと `gccgo` の2つのコンパイラ実装がある」という記述でした。
    *   **変更後**: 「Goには `gc` (`6g` プログラムとその仲間たち) と `gccgo` の2つのコンパイラ実装がある」と修正されました。これは、`6g` が `gc` の一部であるという関係性をより正確に表現し、`gc` がGoの主要なコンパイラ実装であることを強調しています。
*   **`int` のサイズに関する記述**:
    *   **変更前**: 「64ビットGoコンパイラ（`6g` と `gccgo` の両方）は `int` に32ビット表現を使用する」という記述でした。
    *   **変更後**: 「64ビットGoコンパイラ（`gc` と `gccgo` の両方）は `int` に32ビット表現を使用する」と変更されました。ここでも `6g` が `gc` に置き換えられ、より一般的な用語が使用されています。
*   **`gc` コンパイラの開発に関する記述**:
    *   **変更前**: 「オリジナルのGoコンパイラである `6g` をGo自身で書くことを検討したが…」という記述でした。
    *   **変更後**: 「オリジナルのGoコンパイラである `gc` をGo自身で書くことを検討したが…」と変更されました。これは、Goコンパイラ全体（gc）の開発に関する議論であり、特定のアーキテクチャ向けコンパイラ（6g）に限定されないことを明確にしています。
*   **LLVMの使用に関する記述**:
    *   **変更前**: 「`6g` のためにLLVMを使用することも検討したが…」という記述でした。
    *   **変更後**: 「`gc` のためにLLVMを使用することも検討したが…」と変更されました。これも同様に、Goコンパイラ全体（gc）の設計判断に関する記述であり、より適切な用語に修正されています。

これらの変更は、Go言語のドキュメントが、ツールチェインの進化と用語の標準化に合わせて、より正確で最新の情報を提供するように更新されたことを示しています。

## 関連リンク

*   Go言語公式ドキュメント: [https://go.dev/doc/](https://go.dev/doc/)
*   `go command` のドキュメント: [https://go.dev/cmd/go/](https://go.dev/cmd/go/)
*   Go FAQ: [https://go.dev/doc/faq](https://go.dev/doc/faq)

## 参考にした情報源リンク

*   Go言語のコミット履歴 (GitHub): [https://github.com/golang/go/commits/master](https://github.com/golang/go/commits/master)
*   Go言語の初期のツールチェインに関する議論やドキュメント（当時の情報源を特定するのは困難ですが、Goコミュニティのフォーラムや古いブログ記事に言及がある可能性があります。）
*   Go 1.0 リリースノート (go commandの導入に関する情報): [https://go.dev/doc/go1](https://go.dev/doc/go1)
*   Go Wiki - Compiler: [https://go.dev/wiki/Compiler](https://go.dev/wiki/Compiler) (Goコンパイラに関する一般的な情報)
*   Go Wiki - Go Toolchain: [https://go.dev/wiki/GoToolchain](https://go.dev/wiki/GoToolchain) (Goツールチェインに関する一般的な情報)
*   GDBマニュアル: [http://sourceware.org/gdb/current/onlinedocs/gdb/](http://sourceware.org/gdb/current/onlinedocs/gdb/)