cmd/go: consider matching newly added _goos.go, _goarch.go or _goos_goarch.go suffixes based on go.mod go version (rather than Go toolchain version only)

ukxgm1gy  于 6个月前  发布在  Go
关注(0)|答案(6)|浏览(43)

你正在使用哪个版本的Go( go version )?

$ go version
go version go1.16 darwin/amd64

这个问题在最新版本中是否重现?

是的

你正在使用什么操作系统和处理器架构( go env )?

go env 输出

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/conrad/Library/Caches/go-build"
GOENV="/Users/conrad/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/conrad/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/conrad/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.16/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.16/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/conrad/superhuman/backend/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vm/zrl4q9b56y76b3y_d7zspppr0000gn/T/go-build3563792657=/tmp/go-build -gno-record-gcc-switches -fno-common"

你做了什么?

我升级到 go1.16 并运行了 go test

你期望看到什么?

没有失败

你看到了什么?

我的构建失败了,因为我有一个叫做 send_log_ios.go 的文件。在go 1.16之前,这个文件会被包含在构建中(因为没有ios构建标签)。在go 1.16中,由于它被认为与 ios 构建标签匹配,所以这个文件被排除在构建之外。
我的 go.mod 仍然列出了 go 1.15
这对我来说不是问题(我可以直接重命名文件),但我认为这是令人惊讶的,也是go1兼容性承诺的破坏——一个曾经可以构建的程序现在不再构建,因为我升级了我使用的go版本。
我建议只有在我在 go.mod 中更改版本时,才应该发生这种更改。

zdwk9cvp

zdwk9cvp1#

是的,ios现在被认为是一个有效的GOOS值,因此它适用于文件名,与其他GOOS值一样。
我不确定是否应该根据go.mod文件中的语言进行调整。这更多是为了语言更改,而这不是一种语言更改。无论何时发生,这都将是一个令人惊讶的变化,我不认为在更新语言版本时比在更新到新版本时更好。

9njqaruj

9njqaruj2#

https://golang.org/cl/296849提到了这个问题:_content/doc/go1.16: explicit point out ios as a build tag

bcs8qyzn

bcs8qyzn3#

谢谢!我认为文档澄清CL是有帮助的。再次阅读兼容性承诺,我确实看到虽然它说“编写到Go 1规范的程序将在该规范的整个生命周期中继续编译和运行正确,不变”,但似乎规范根本没有提到构建标签或哪些文件包含在构建中。这对我来说非常令人惊讶!基于go.mod版本号的主要优点是,如果我依赖于具有这些文件的任何模块,我的应用程序将继续构建,即使我升级了编译器版本(构建标签提案通过将旧语法永久保留为有效来解决此问题,但在这里这不是一个选项)...

2021年2月26日星期五,GopherBot <***@***.***>写道:更改https://golang.org/cl/296849(https://golang.org/cl/296849)提到了这个问题:_content/doc/go1.16:明确指出ios作为构建标签—您收到此邮件是因为您创建了这个线程。直接回复此电子邮件,查看GitHub(#44626(评论)),或取消订阅(https://github.com/notifications/unsubscribe-auth/AAAXAQGCOJCW7JH7KH2ZLZDTA64UVANCNFSM4YH2HJGQ)。

l7wslrjt

l7wslrjt4#

我同意这个功能按预期工作,并且与过去在GOOS/GOARCH值中保留新值时的行为一致。
由于这个问题仍然开放,我已经添加了一个需要调查的标签,以便在未来确定是否应该采取不同的行动(例如,评估是否最好将更改与go.mod的版本绑定,正如您建议的那样)。
CC @bcmills,@matloob,@jayconrod。

63lcw9qa

63lcw9qa5#

go 版本故意不对 显式 构建标签进行门控,即使是与 GOOSGOARCH 值对应的标签。然而,对于将来扩展到 GOARCHGOOS 的任何情况,也许我们应该使新添加的 隐式 构建约束取决于 go.mod 文件中的 go 语言版本。
更改现有文件名的解释(从非约束变为约束,反之亦然)似乎非常明显地是一个重新定义(在 http://golang.org/design/28221-go2-transitions#language-redefinitions 的意义上)。另一方面,将某些 GOOS 值的隐式约束应用于其他值会非常令人困惑,完全删除隐式构建约束支持也是一种同样糟糕的重新定义。
我认为这里没有好的选择。

gcmastyq

gcmastyq6#

我们努力将所有合理的CPU值添加到有效的GOARCH值列表中。我想知道是否可以向有效的GOOS值列表中添加一些值。

相关问题