特定のファイルをエディターのファイル リストの一番上に表示したかったので、_
. これはどのように見えるかです:
mypkg
_func.go
a.go
b.go
などを使用_test
したGoのファイル命名規則については知っていますが、特定のアーキテクチャに一致しないか、テストケースであるため、ソースファイルとしてカウントされないのはなぜですか?_unix
_func
このパッケージをインポートすると、このファイルで定義された関数は使用できません。
特定のファイルをエディターのファイル リストの一番上に表示したかったので、_
. これはどのように見えるかです:
mypkg
_func.go
a.go
b.go
などを使用_test
したGoのファイル命名規則については知っていますが、特定のアーキテクチャに一致しないか、テストケースであるため、ソースファイルとしてカウントされないのはなぜですか?_unix
_func
このパッケージをインポートすると、このファイルで定義された関数は使用できません。
どうやら、アンダースコアはファイルの先頭にあるドットプレフィックスと同じ重みを持ち、go build
コマンドによって明らかに無視されます。go
ただし、これはツールの決定ではなくgo/build
、標準ライブラリのパッケージの決定です。担当の行はこちらで確認できます。
私の推測では、一時ファイルにはアンダースコアがプレフィックスとして付けられているため、ビルド ツール チェーンによって無視されます。
編集:このコメントは動作を文書化しています。私は引用します:
// Import returns details about the Go package named by the import path,
// interpreting local import paths relative to the srcDir directory.
// If the path is a local import path naming a package that can be imported
// using a standard import path, the returned package will set p.ImportPath
// to that path.
//
// In the directory containing the package, .go, .c, .h, and .s files are
// considered part of the package except for:
//
// - .go files in package documentation
// - files starting with _ or . (likely editor temporary files)
// - files with build constraints not satisfied by the context
//
// If an error occurs, Import returns a non-nil error and a non-nil
// *Package containing partial information.
//
これは、 package のパッケージ ドキュメントgo/build
でユーザー フレンドリーな形式で見つけることができます。
これは、ドットファイル ( ) がシェルに隠されている_whatever
のと同様の方法で go ツールによって処理されたことを思い出すと思います。.whatever
残念ながら、それが文書化されている場所への参照が見つかりません。
そのため、私のメモリが正しくサーバー化されている場合は、ソースファイルの名前を変更する必要があります。これは、Go ビルドシステムと互換性がないため、_file.go
パッケージの一部と見なす必要がある場合です。
この動作の意図は、おそらく、CGO などのツール用の一時的で競合しないファイルを簡単に作成できるようにすることです。