Golang构建约束随机 [英] Golang Build Constraints Random

问题描述

我在标头中有两个具有不同构建约束的go文件.

I have two go files with different build constraints in the header.

constants_production.go:

constants_production.go:

// +build production,!staging

package main

const (
  URL               = "production"
)

constants_staging.go:

constants_staging.go:

// +build staging,!production

package main

const (
  URL               = "staging"
)

main.go:

package main

func main() {
  fmt.Println(URL)
}

当我执行 go install -tags"staging" 时，有时会打印 production ；有时，它会打印 staging .同样，当我 go install -tags"production" ，...

When I do a go install -tags "staging", sometimes, it prints production; Sometimes, it prints staging. Similarly, when I do go install -tags "production",...

如何在每个版本上获得一致的输出?将暂存指定为构建标志时，如何使它打印暂存?当将生产指定为构建标记时，如何使其打印生产?我在这里做错什么了吗?

How do I get a consistent output on every build? How do I make it print staging when I specify staging as a build flag? How do I make it print production when I specify production as a build flag? Am I doing something wrong here?

推荐答案

进行构建和进行安装如果看起来像什么都没有，将不会重建软件包(二进制)已更改-并且它对命令行构建标签中的更改不敏感.

go build and go install will not rebuild the package (binary) if it looks like nothing has changed -- and it's not sensitive to changes in command-line build tags.

一种查看方法是添加 -v 以在构建软件包时打印软件包:

One way to see this is to add -v to print the packages as they are built:

$ go install -v -tags "staging"
my/server
$ go install -v -tags "production"
(no output)

您可以通过添加 -a 标志来强制进行重建，这通常会导致过大的破坏:

You can force a rebuild by adding the -a flag, which tends to be overkill:

$ go install -a -v -tags "production"
my/server

...或在构建之前触摸服务器源文件:

...or by touching a server source file before the build:

$ touch main.go
$ go install -a -tags "staging"

...或在构建之前手动删除二进制文件:

...or manually remove the binary before the build:

$ rm .../bin/server
$ go install -a -tags "production"

这篇关于Golang构建约束随机的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！