我希望一个特定的文件出现在我的编辑器中我的文件列表的顶部,所以我在它前面加上了_
. 这是它的外观:
mypkg
_func.go
a.go
b.go
我知道 Go 的文件命名约定使用_test
等_unix
,但是,由于_func
与特定架构不匹配或者是测试用例,为什么它不能算作源文件?
当我导入这个包时,这个文件中定义的函数不可用。
我希望一个特定的文件出现在我的编辑器中我的文件列表的顶部,所以我在它前面加上了_
. 这是它的外观:
mypkg
_func.go
a.go
b.go
我知道 Go 的文件命名约定使用_test
等_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 工具以类似的方式处理 dotfiles ( .whatever
) 是如何隐藏在 shell 中的。不幸的是,我找不到任何关于它记录在哪里的参考。
因此,如果我的内存服务器正确,您将不得不重命名源文件,因为它与 Go 构建系统不兼容,如果您打算将此类_file.go
视为某个包的一部分。
这种行为的目的可能是为了方便为 CGO 等工具创建临时且不冲突的文件。