Go Build Constraints

This is a creation in Article, where the information may have evolved or changed.

The go language has a no (odd) error (constraints) design, which is the build constraint. You can specify the compilation options in the source code in the form of annotations, such as only allowed under Linux, or on a 386 platform, and can be constrained by file names, such as Xxxx_linux.go, which is only allowed to compile under Linux, Xxx_windows_ Amd64.go is only allowed to be compiled under Windows x64.

Build constraints can be used in many files, not just go files. It is important to note, however, that building constraints are implemented through annotations, such as placing them at the beginning of a file, prior to empty lines or other annotations. This means that you must write in front of the package statement. This has a very painful file, because Go's Godoc can extract comments from the code and then convert them into documents. Comments written before the package statement are considered to be packet-level comments. And before all annotations are constructed, it is necessary to differentiate between building constraints and package-level annotations by adding blank lines to distinguish between comments at the package level. (The design seems to have to admit that it's embarrassing).

The construction constraints implemented by annotations can also be logically expressed. is semantics such as and, or. The official go is defined as: if there are spaces in the build constraints, then the or relationship, if separated by commas, is the and relationship. Represents not. Like what

+build linux,386 Darwin,!cgo

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

And go also supports multi-line build constraints, where multiple rows are and relationships, such as

+build Linux Darwin

+build 386

That means (Linux OR Darwin) and 386

Go official also defines some of the commonly used constraints

• Restrict the target operating system, that is, the runtime. Goos consistent
• Limit the target schema platform, which is to and runtime. Goarch consistent
• Constraints supported by compilers such as GC or GCCGO
• CGO constraints, which means that if you support CGO, you can participate in the compilation
• go1.1, which means forward compatibility starting from go1.1
• go1.2, indicating forward compatibility starting from 1.2
• Go.13, indicating forward compatibility starting from 1.3
• Custom Constraints

If you want to temporarily let a file not participate in the compilation, you can add a comment constraint: //+build Ignore

Using annotations to implement build constraints a bit of an egg ache, and the go official definition also means that you can customize the constraints, so what can you do? Everyone who learns go knows that go has a framework for unit testing, and it's very nice to run general unit tests, but if you want to do some simple integration testing, it's a little bit easier, because go test defaults to running the most basic unit tests. So how do you just execute the code for the integration test? You can actually implement it by building constraints. For example, we add //+build integration to the go file of the integration test and then run the command go test–tags= "integration" to run our integration test code only.

Although constructs are constrained by annotations, the construction constraints of filenames are quite good, at least in engineering. The filename prefix as long as contains _goos, _goarch, _goos_goarch can be. such as Xxx_linux.go Yyy_windows_amd64.go, Zzzz_386.s and so on.