我可以基于我正在构建的操作系统导入Golang包吗？

Question

假设我有一个基于哪个操作系统的go项目，在某些情况下是哪个发行版，我想使用Systemd客户端包对Upstart客户端包与sysv客户端包和launchd客户端包。是否有可能有选择地导入每个包，因此我只导入我构建的每个OS/发行版所需的包？还是我必须为每个OS/发行版导入每个包？

Answer 1

包构建 构建约束 构建约束(也称为build标记)是一个开始的行注释。 // +构建 它列出了包中应包含文件的条件。约束可能出现在任何类型的源文件中(不仅仅是Go)，但是它们必须出现在文件顶部附近，前面只有空行和其他行注释。这些规则意味着，在Go文件中，构建约束必须出现在package子句之前。 要将生成约束与包文档区分开来，必须在一系列生成约束后面加上一个空行。 build约束被计算为空格分隔选项的or；每个选项计算为其逗号分隔的术语的和；每个术语是字母数字词，或者，前面是它的否定词。也就是说，构建约束： // +构建linux,386达尔文，！ 对应于布尔公式： (linux和386) OR (达尔文和(不是cgo)) 一个文件可能有多个构建约束。总体约束是单个约束的约束。也就是说，构建约束： // +构建linux达尔文/ +build 386 对应于布尔公式： (linux或达尔文)和386 在特定的构建过程中，满足以下单词：

• 目标操作系统，如runtime.GOOS所拼写的--目标体系结构，由runtime.GOARCH拼写--编译器正在使用"gc“或"gccgo”--“ctxt.CgoEnabled”，如果ctxt.CgoEnabled是真的-- "go1.1"，从Go版本1.1继续-- "go1.2"，从Go版本1.2继续-- "go1.3"，从Go版本1.3继续-- "go1.4"，从Go版本1.4继续-- "go1.5"，从Go版本1.5继续-- "go1.6"，从Go版本1.6继续-- ctxt.BuildTags中列出的任何其他单词 如果在去掉扩展名和可能的_test后缀后，文件的名称与下列任何模式相匹配： *_GOOS *_GOARCH *_GOOS_GOARCH (例如: source_windows_amd64.go)，其中GOOS和GOARCH分别代表任何已知的操作系统和体系结构值，那么文件被认为具有一个要求这些术语的隐式构建约束(除了文件中的任何显式约束)。 若要防止文件被考虑用于生成，请执行以下操作： // +构建忽略 (任何其他不满意的词也会起作用，但“忽略”是传统的。) 仅在使用cgo时，并且仅在Linux和OS上构建文件： // +构建linux、cgo达尔文、cgo 这样的文件通常与实现其他系统的默认功能的另一个文件配对，在这种情况下，该文件带有约束： // +构建!linux，！达尔文!cgo 命名一个文件dns_windows.go只会导致它只在构建用于math_386.s的包时包含；类似地，只有在为32位x86构建包时才会包含math_386.s。 除了使用GOOS=android标记和文件之外，使用GOOS=linux还可以匹配构建标记和文件。

使用构建约束。

使用包含多个文件的单个包。每个文件都专门针对特定的操作系统、体系结构等组合。

Answer 2

构建约束被计算为空格分隔选项的or；每个选项计算为其逗号分隔术语的和；每个术语是字母数字单词或，前面有！

实际上，这将改变用Go 1.17 (Q3 2021)

//go:build线 go命令现在理解//go:build行，并更喜欢它们而不是// +build行。 新的语法使用布尔表达式，就像Go一样，并且应该不容易出错。 在这个版本中，新语法得到了完全支持，所有Go文件都应该被更新，使其具有相同的含义。 为了帮助迁移，gofmt现在自动同步这两种表单。 有关语法和迁移计划的详细信息，请参阅https://golang.org/design/draft-gobuild。

在设计文件中：

该设计的核心思想是将当前用于构建标记选择的// +build行替换为使用更熟悉的布尔表达式的新//go:build行。 例如，旧语法 // +构建linux / +build 386 将被新语法替换。 //go:构建linux && 386