你正在使用哪个版本的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
中更改版本时,才应该发生这种更改。
6条答案
按热度按时间zdwk9cvp1#
是的,
ios
现在被认为是一个有效的GOOS
值,因此它适用于文件名,与其他GOOS
值一样。我不确定是否应该根据go.mod文件中的语言进行调整。这更多是为了语言更改,而这不是一种语言更改。无论何时发生,这都将是一个令人惊讶的变化,我不认为在更新语言版本时比在更新到新版本时更好。
9njqaruj2#
https://golang.org/cl/296849提到了这个问题:
_content/doc/go1.16: explicit point out ios as a build tag
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)。
l7wslrjt4#
我同意这个功能按预期工作,并且与过去在GOOS/GOARCH值中保留新值时的行为一致。
由于这个问题仍然开放,我已经添加了一个需要调查的标签,以便在未来确定是否应该采取不同的行动(例如,评估是否最好将更改与go.mod的版本绑定,正如您建议的那样)。
CC @bcmills,@matloob,@jayconrod。
63lcw9qa5#
go
版本故意不对 显式 构建标签进行门控,即使是与GOOS
或GOARCH
值对应的标签。然而,对于将来扩展到GOARCH
和GOOS
的任何情况,也许我们应该使新添加的 隐式 构建约束取决于go.mod
文件中的go
语言版本。更改现有文件名的解释(从非约束变为约束,反之亦然)似乎非常明显地是一个重新定义(在 http://golang.org/design/28221-go2-transitions#language-redefinitions 的意义上)。另一方面,将某些
GOOS
值的隐式约束应用于其他值会非常令人困惑,完全删除隐式构建约束支持也是一种同样糟糕的重新定义。我认为这里没有好的选择。
gcmastyq6#
我们努力将所有合理的CPU值添加到有效的
GOARCH
值列表中。我想知道是否可以向有效的GOOS
值列表中添加一些值。