假设我有一个go项目,该项目基于哪个OS,在某些情况下取决于哪个发行版,我想使用一个Systemd客户端软件包vs Upstart客户端软件包vs sysv客户端软件包vs已启动的客户端软件包。是否可以有选择地导入每个软件包,以便仅导入要为其构建的每个OS /发行版所需的软件包?还是我必须为每个操作系统/发行版导入每个软件包?
包构建 建立约束 构建约束,也称为构建标记,是开始的行注释 // +build 列出了在文件中应包含文件的条件。约束可能会出现在任何类型的源文件中(不仅是Go),但它们必须出现在文件顶部附近,并且只能出现空白行和其他行注释。这些规则意味着在Go文件中,构建约束必须出现在package子句之前。 为了将构建约束与程序包文档区分开,必须在一系列构建约束后跟空白行。 将构建约束评估为以空格分隔的选项的OR。每个选项的求值均以其逗号分隔的术语的AND表示;并且每个术语都是字母数字单词,或者在其前面加!的取反。也就是说,构建约束: // +build linux,386 darwin,!cgo 对应于布尔公式: (linux AND 386) OR (darwin AND (NOT cgo)) 一个文件可能有多个构建约束。总体约束是各个约束的AND。也就是说,构建约束: // +build linux darwin // +build 386 对应于布尔公式: (linux OR darwin) AND 386 在特定的构建过程中,满足以下条件: - 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 - any additional words listed in ctxt.BuildTags 如果在删除扩展名和可能的_test后缀后,文件名与以下任何一种模式匹配: *_GOOS *_GOARCH *_GOOS_GOARCH (示例:source_windows_amd64.go),其中GOOS和GOARCH分别表示任何已知的操作系统和体系结构值,然后该文件被视为具有需要这些术语的隐式构建约束(除了文件中的任何显式约束)。 要避免考虑将文件用于构建: // +build ignore (其他任何不满意的词也可以使用,但是“忽略”是常规的。) 要仅在使用cgo且仅在Linux和OS X上构建文件: // +build linux,cgo darwin,cgo 这样的文件通常与另一个文件配对,该文件实现了其他系统的默认功能,在这种情况下,它将带有约束: // +build !linux,!darwin !cgo 命名文件dns_windows.go将导致仅在构建Windows软件包时才包含该文件;同样,仅当为32位x86构建软件包时,才会包括math_386.s。 除了Android标记和文件之外,使用GOOS = android还可以像GOOS = linux一样匹配构建标记和文件。
包构建
建立约束
构建约束,也称为构建标记,是开始的行注释
// +build
列出了在文件中应包含文件的条件。约束可能会出现在任何类型的源文件中(不仅是Go),但它们必须出现在文件顶部附近,并且只能出现空白行和其他行注释。这些规则意味着在Go文件中,构建约束必须出现在package子句之前。
为了将构建约束与程序包文档区分开,必须在一系列构建约束后跟空白行。
将构建约束评估为以空格分隔的选项的OR。每个选项的求值均以其逗号分隔的术语的AND表示;并且每个术语都是字母数字单词,或者在其前面加!的取反。也就是说,构建约束:
// +build linux,386 darwin,!cgo
对应于布尔公式:
(linux AND 386) OR (darwin AND (NOT cgo))
一个文件可能有多个构建约束。总体约束是各个约束的AND。也就是说,构建约束:
// +build linux darwin // +build 386
(linux OR darwin) AND 386
在特定的构建过程中,满足以下条件:
- 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 - any additional words listed in ctxt.BuildTags
如果在删除扩展名和可能的_test后缀后,文件名与以下任何一种模式匹配:
*_GOOS *_GOARCH *_GOOS_GOARCH
(示例:source_windows_amd64.go),其中GOOS和GOARCH分别表示任何已知的操作系统和体系结构值,然后该文件被视为具有需要这些术语的隐式构建约束(除了文件中的任何显式约束)。
要避免考虑将文件用于构建:
// +build ignore
(其他任何不满意的词也可以使用,但是“忽略”是常规的。)
要仅在使用cgo且仅在Linux和OS X上构建文件:
// +build linux,cgo darwin,cgo
这样的文件通常与另一个文件配对,该文件实现了其他系统的默认功能,在这种情况下,它将带有约束:
// +build !linux,!darwin !cgo
命名文件dns_windows.go将导致仅在构建Windows软件包时才包含该文件;同样,仅当为32位x86构建软件包时,才会包括math_386.s。
除了Android标记和文件之外,使用GOOS = android还可以像GOOS = linux一样匹配构建标记和文件。
使用构建约束。
将单个软件包与多个文件一起使用。每个文件都专门针对特定的OS,体系结构等组合。