Go build Constraints

The Go language has a NO (ODD) Error design, that is, build constraints (build constraints ). You can specify the compilation options in the source code by commenting, for example, compiling only in Linux or on the 386 platform. You can also restrict the construction by file names, for example, xxxx_linux.go can only be compiled in Linux, and xxx_windows_amd64.go can only be compiled in Windows x64.

Build constraints can be used in many files, not just go files. However, you must note that, for example, to place a constraint at the beginning of a file, it should take precedence over empty lines or other annotations. That is to say, it must be written before the package statement. This is a tough file, because go's godoc can extract comments from the code and convert them into documents. Comments written before a package statement are considered package-level comments. Before all annotations are built, empty lines must be added between the build constraint and the package-level annotation to distinguish packet-level annotations. (This design seems to have to admit that it is awesome ).

The construction constraints of annotation implementation can also be logically expressed. It is the semantics such as "and" or. The official definition of Go is as follows: if there are spaces in the building constraints, it is the or relation. If it is separated by commas, It is the and relation .! Not. For example

// + Build Linux, 386 Darwin ,! CGO

Represents (Linux and 386) or (Darwin and (not CGO ))

In addition, go also supports the construction constraints of multiple rows, and the relationship between multiple rows is and, for example

// + Build Linux Darwin

// + Build 386

It means (Linux or Darwin) and 386

Go also defines common constraints.

• Restrict the target operating system, that is, it must be consistent with runtime. GOOS.
• Restrict the target architecture platform, that is, it must be consistent with runtime. goarch.
• Restrictions supported by GC, gccgo, and other compilers
• CGO constraints, that is, if CGO is supported, you can participate in compilation.
• Go1.1, indicating forward compatibility from go1.1
• Go1.2, indicating forward compatibility from 1.2
• Go.13, indicating forward compatibility from 1.3
• Custom Constraints

If you want to temporarily prevent a file from being compiled, you can add the following annotations:// + Build ignore

It is a bit painful to use annotations to implement building constraints, and the go official definition also indicates that custom constraints can be defined. So what can be used? Everyone who learns to go knows that go has a built-in unit test framework, and it is still very easy to run a general unit test. However, if you want to do some simple integration tests, it will be unfeasible, because go test is the most basic unit test by default. So how can we only execute the integration test code? In fact, we can implement it by constructing constraints. For example, we add// + Build IntegrationThen run go test-tags = "integration" to run only our integration test code.

Although the construction is constrained by the annotation method, the construction constraint of the file name is quite good, at least clearly visible in the project. The file name prefix can only contain _ GOOS, _ goarch, and _ goos_goarch. For example, xxx_linux.go yyy_windows_amd64.go and zzzz_386.s.

Go build Constraints