比十万多一点

毕方

0%

使用go build -tags生成多种实现

发表于 更新于 分类于 Disqus：

语法规则和构建约束

构建约束（也称为构建标记）用注释行表示，格式如下：

1
// +build
  1. 构建约束以一行+build开始的注释。在+build之后列出了一些条件，在这些条件成立时，该文件应包含在编译的包中；
  2. 约束可以出现在任何源文件中，不限于go文件；
  3. +build必须出现在package语句之前，+build注释之后应要有一个空行。
  4. 只允许字母数字或_

构建约束 多个选项之间空格分隔表示为OR，多个选项之间逗号分隔表示为AND。 每个选项都是一个字母数字的单词，或者以！开头表示否定。也就是说，构建约束：

1
// +build linux,386 darwin,!cgo

等同于：

1
(linux AND 386) OR (darwin AND (NOT cgo))

一个文件可以包含多行构建约束。多行之间的约束表示为AND：

1
2
// +build linux darwin
// +build 386

等同于：

1
(linux OR darwin) AND 386

以下单词支持特殊编译：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- the target operating system, as spelled by runtime.GOOS
- the target architecture, as spelled by runtime.GOARCH
- the compiler being used, either "gc" or "gccgo"
- "cgo", if ctxt.CgoEnabled is true
- "go1.1", from Go version 1.1 onward
- "go1.2", from Go version 1.2 onward
- "go1.3", from Go version 1.3 onward
- "go1.4", from Go version 1.4 onward
- "go1.5", from Go version 1.5 onward
- "go1.6", from Go version 1.6 onward
- "go1.7", from Go version 1.7 onward
- "go1.8", from Go version 1.8 onward
- "go1.9", from Go version 1.9 onward
- "go1.10", from Go version 1.10 onward
- any additional words listed in ctxt.BuildTags

除去文件扩展名和_test后缀，符合以下文件名称格式的也将纳入构建约束：

1
2
3
4
5
6
7
8
9
10
11
*_GOOS
*_GOARCH
*_GOOS_GOARCH

// example
hello_darwin.go
hello_linux.go
hello_windows.go

// example
source_windows_amd64.go

GOOS和GOARCH表示为已知的操作系统和体系架构值，这类的文件被认为具有需要这些隐式构建约束。

让文件不被用于构建，任何其他不满意的词也会起作用，但“忽略”是符合传统的。

1
// +build ignore

更多详细信息，可以查看go/build/build.go文件中shouldBuild和match方法。参考：https://golang.org/pkg/go/build/

应用实例1

除了*_GOOS这种预定义的应用，我们看一个实际的应用。

比如，项目中需要在测试环境输出Debug信息，一般通过一个变量（或常量）来控制是测试环境还是生产环境，比如：if DEBUG {}，这样在生产环境每次也会进行这样的判断。在golang-nuts邮件列表中有人问过这样的问题，貌似没有讨论出更好的方法（想要跟C中条件编译一样的效果）。下面我们采用Build constraints来实现。

1）文件列表：main.go logger_debug.go logger_product.go

2）在main.go中简单的调用Debug()方法。

3）在logger_product.go中的Debug()是空实现，但是在文件开始加上// + build !debug

4）在logger_debug.go中的Debug()是需要输出的调试信息，同时在文件开始加上// + build debug

这样，在测试环境编译的时传递-tags参数：go build/install -tags “debug” logger。生产环境：go build/install logger就行了。

对于生产环境，不传递-tags时，为什么会编译logger_product.go呢？因为在go/build/build.go中的match方法中有这么一句：

1
2
3
if strings.HasPrefix(name, "!") { // negation
    return len(name) > 1 && !ctxt.match(name[1:])
}

也就是说，只要有!（不能只是!），tag不在BuildTags中时，总是会编译。

应用实例2

本例程中，编译的tag差异较大，两个文件中一个是hash tag，一个是int tag，需要引入第三个tag来区分编译的文件。否则，只要不带！的tag都会被编译进包。

项目工程目录结构

1
2
3
|- main.go
|- display_hash.go
|- display_int.go

main.go源码

1
2
3
4
5
6
package main

// 编译执行过程 go build -tags "display_alternatives int" .
func main() {
	x
}

DisplayName的两种实现

display_hash.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// +build hash !display_alternatives

// 上面
package main

import "fmt"

type DisplayName string

func Print(name DisplayName) {
	fmt.Printf("%s\n", name)
}

func MakeDisplayName(name string) DisplayName {
	return DisplayName(name)
}

display_int.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// +build int

package main

import (
	"fmt"
	"encoding/hex"
	"encoding/binary"
)

type DisplayName uint64

func Print(name DisplayName) {
	fmt.Printf("%d\n", name)
}

func MakeDisplayName(name string) DisplayName {
	h, err := hex.DecodeString(name)
	if err != nil {
		panic(fmt.Sprintf("decode hex string failed. cause: %v\n", err))
	}
	fmt.Printf("data: %v\n", h)

	value := binary.BigEndian.Uint16(h)
	return DisplayName(value)
}

编译display_int.go
编译执行过程 go build -tags "display_alternatives int"

编译display_hash.go
编译执行过程 go build -tags hash