`cmd/go`:应该帮助用户了解何时新的`GOOS`或`GOARCH`破坏了他们的构建,

8e2ybdfx  于 5个月前  发布在  Go
关注(0)|答案(5)|浏览(70)

今天在Slack工作区的Go新手频道中,我们遇到了一个有趣的问题,具体是关于用户在Go v1.10.x和v1.11.x之间的构建破坏。我不确定这里是否真的有一个可行的解决方案,但我认为与Go作者讨论一下是值得的。
这个用户从Go v1.10.x升级到Go v1.11.2,代码没有做其他更改,然后遇到了构建失败:

./swaguidist.go:15:38: undefined: swaggerUiBundleJs
./swaguidist.go:17:38: undefined: swaggerUiStandalonePresetJs

当用户试图找出问题所在时,他们错误地断定,由于包中的一些文件较大,编译器忽略了它们。他们向Slack工作区寻求帮助,看看是否有人知道这样的限制,但幸运的是,我们碰巧发现了以*_js.go结尾的文件。
虽然我认为理想情况下应该让每个人都完整阅读发布说明,但我认为我们永远不会达到那个地方。这让我不禁思考,是否有任何选项可以让我们更容易地接近和采取行动(尤其是对新手),而不是像未定义变量这样的错误。

jjjwad0x

jjjwad0x1#

是的,这种对文件名处理方式的变化是一个持续缓慢的问题。

6jygbczu

6jygbczu2#

FTR:这与语言变更破坏构建无关。构建系统并非语言本身。

up9lanfz

up9lanfz3#

#28221 中引入的机制是否应该用于忽略尚未由模块记录的语言版本保留的构建约束?

wfypjpf4

wfypjpf44#

@cznic 感谢,已更新问题标题。
@jimmyfrasche 我担心依赖这个可能会增加困惑而不是减少它。

nr9pn0ug

nr9pn0ug5#

尽管语言版本切换可能令人困惑,但我怀疑它是选项中最不令人困惑的:至少,它保留了这样一个属性:在一个版本中结构正确的程序在时间上仍保持结构正确。

相关问题