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

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

コミット

コミットハッシュ: bbdd2070a92adedaa60e91cc14791daf01ba8deb
作成者: Christopher Wedgwood cw@f00f.org
日時: 2011年12月20日 15:54:39 (EST)
コミットメッセージ: .hgignore: ignore autogenerated files

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

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

元コミット内容

このコミットは.hgignoreファイルに自動生成されるファイルを無視するパターンを追加する変更です。具体的には、以下の5つのパターンが追加されました:

  1. src/pkg/runtime/arch_GOARCH.h
  2. src/pkg/runtime/defs_GOOS_GOARCH.h
  3. src/pkg/runtime/os_GOOS.h
  4. src/pkg/runtime/signals_GOOS.h
  5. src/pkg/runtime/z*

この変更により、Goランタイムのビルドプロセスで自動生成されるプラットフォーム固有のヘッダーファイルがバージョン管理システムによって追跡されなくなりました。

変更の背景

2011年12月の時点で、Goプログラミング言語はまだMercurialを使用してバージョン管理を行っていました。この時期はGo 1.0のリリース(2012年3月)を目前に控えた重要な開発期間でした。

Goプロジェクトでは当時、以下のような変遷を経ていました:

  • Subversion → Perforce → Mercurial → Git(2014年)という順序で、これが4番目のバージョン管理システムとなりました
  • 2014年11月にGitHubへの移行を発表し、Go 1.4リリース後にMercurialからGitへの完全移行を実施

この時期のGoランタイムは、マルチプラットフォーム対応のために多数のプラットフォーム固有のファイルを自動生成する必要があり、それらのファイルをバージョン管理から除外する必要がありました。

前提知識の解説

Mercurialの.hgignoreファイル

Mercurialにおける.hgignoreファイルは、バージョン管理システムが追跡すべきでないファイルを指定するためのファイルです。これは:

  • リポジトリのルートディレクトリに配置される
  • バージョン管理下に置かれ、push/pullで他のリポジトリに伝播される
  • 正規表現やglob形式のパターンマッチングをサポート
  • エディタのバックアップファイルやコンパイラの生成物などを除外するために使用

Goのプラットフォーム固有ファイルシステム

Goは設計時からクロスプラットフォーム対応を念頭に置いており、以下の仕組みを使用してプラットフォーム固有のコードを管理しています:

  1. 環境変数による制御

    • GOOS:ターゲットオペレーティングシステム(darwin, freebsd, linux, windows等)
    • GOARCH:ターゲットアーキテクチャ(amd64, 386, arm, arm64等)
  2. ファイル命名規則

    • _$GOOS.go:特定のOS向けファイル
    • _$GOARCH.go:特定のアーキテクチャ向けファイル
    • _$GOOS_$GOARCH.go:OS・アーキテクチャ固有ファイル
  3. ビルドタグ

    • // +build linux(古い形式)
    • //go:build linux(Go 1.17以降の推奨形式)

技術的詳細

自動生成ファイルのパターン解析

今回追加された各パターンの技術的意味は以下の通りです:

  1. src/pkg/runtime/arch_GOARCH.h

    • アーキテクチャ固有の定義ファイル
    • 例:arch_amd64.h, arch_arm.h, arch_386.h
    • CPUアーキテクチャに依存する定数、構造体定義、マクロを含む
  2. src/pkg/runtime/defs_GOOS_GOARCH.h

    • OS・アーキテクチャ固有の定義ファイル
    • 例:defs_linux_amd64.h, defs_darwin_amd64.h
    • システムコールインターフェース、カーネル構造体、プラットフォーム固有の定数を含む
  3. src/pkg/runtime/os_GOOS.h

    • OS固有の定義ファイル
    • 例:os_linux.h, os_darwin.h, os_windows.h
    • オペレーティングシステム固有の機能、APIインターフェースを含む
  4. src/pkg/runtime/signals_GOOS.h

    • OS固有のシグナル処理定義ファイル
    • 例:signals_linux.h, signals_darwin.h
    • シグナル番号、シグナルハンドラ、プラットフォーム固有のシグナル処理を含む
  5. src/pkg/runtime/z*

    • 'z'で始まる全てのファイル(通常は自動生成されるファイルの命名規則)
    • アセンブリコード、CGOバインディング、その他のツールによって生成されるファイル

ビルドプロセスでの生成タイミング

これらのファイルは、Goのビルドプロセスの以下の段階で生成されます:

  1. プリプロセス段階

    • go buildコマンドの実行時
    • ターゲットプラットフォームの検出(GOOS/GOARCH環境変数)
    • プラットフォーム固有のヘッダーファイル生成
  2. コンパイル段階

    • ランタイムパッケージのコンパイル
    • アーキテクチャ固有のアセンブリコード生成
    • システムコールラッパーの生成
  3. リンク段階

    • プラットフォーム固有のランタイムライブラリとのリンク
    • 実行可能ファイルの生成

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

diff --git a/.hgignore b/.hgignore
index 11a0773a05..81c3d41560 100644
--- a/.hgignore
+++ b/.hgignore
@@ -49,12 +49,17 @@ src/pkg/exp/ebnflint/ebnflint
 src/pkg/go/build/syslist.go
 src/pkg/go/doc/headscan
 src/pkg/runtime/*/asm.h
+src/pkg/runtime/arch_GOARCH.h
+src/pkg/runtime/defs_GOOS_GOARCH.h
 src/pkg/runtime/goc2c
 src/pkg/runtime/mkversion
+src/pkg/runtime/os_GOOS.h
 src/pkg/runtime/runtime.acid.*
 src/pkg/runtime/runtime_defs.go
+src/pkg/runtime/signals_GOOS.h
 src/pkg/runtime/version.go
 src/pkg/runtime/version_*.go
+src/pkg/runtime/z*
 src/pkg/unicode/maketables
 src/pkg/*.*/
 test/pass.out

コアとなるコードの解説

追加されたパターンの意味

この変更は、Goランタイムのビルドシステムが進化し、より洗練された自動生成ファイル管理システムを導入したことを示しています。

  1. プラットフォーム固有パターンの体系化

    • arch_GOARCH.h:アーキテクチャレベルの抽象化
    • defs_GOOS_GOARCH.h:OS・アーキテクチャ組み合わせの具体化
    • os_GOOS.h:オペレーティングシステムレベルの抽象化
    • signals_GOOS.h:シグナル処理の標準化
  2. ワイルドカードパターンz*の意味

    • 動的に生成されるファイルの命名規則
    • CGOによって生成されるファイル(例:z_runtime_cgo.c
    • アセンブリスタブファイル(例:z_linux_amd64.s
    • その他のツールチェーンが生成するファイル
  3. 既存パターンとの整合性

    • src/pkg/runtime/*/asm.h:既存のアセンブリヘッダーパターン
    • src/pkg/runtime/runtime.acid.*:デバッグ情報ファイル
    • src/pkg/runtime/version_*.go:バージョン情報ファイル

なぜこの変更が必要だったのか

  1. ビルドシステムの進化

    • Go 1.0に向けた安定化プロセス
    • より多くのプラットフォームサポートの追加
    • ビルドプロセスの自動化と標準化
  2. 開発者体験の向上

    • クリーンなリポジトリ状態の維持
    • hg statusでの不要なファイル表示の回避
    • コミット時の誤った自動生成ファイル追加の防止
  3. CI/CDの準備

    • 自動ビルドシステムでの一貫性保証
    • 異なる環境での再現可能なビルド
    • プラットフォーム固有ファイルの衝突回避

関連リンク

参考にした情報源リンク