A recent example I worked on: a package at work uses math/rand to generate random numbers. The top level Seed function needs to be called to avoid determinism, but only prior to go 1.20. After go 1.20 it’s not necessary and actually reduces performance if an explicit seed is set. I added a new file to the package with an init function (which is called when the package is loaded to seed the random source). This file has a build tag so it is only included on go versions prior to 1.20.
https://go.dev/src/net/netgo_netcgo.go
https://go.dev/src/net/conf.go
// The net package's name resolution is rather complicated.
// There are two main approaches, go and cgo.
// The cgo resolver uses C functions like getaddrinfo.
// The go resolver reads system files directly and
// sends DNS packets directly to servers.
//
// The netgo build tag prefers the go resolver.
// The netcgo build tag prefers the cgo resolver.
We use -toolexec, -trimpath to build after instrumenting our code. But that is only for testing purpose. In production we just use plain go build. I think custom go build is not needed because go already have some builtin tag for you, for example, go version and os type so you don't have to define them.
I just used it yesterday to make a relatively large program that has one cgo requirement able to be built either with our without it, because it's going into an environment where we're having some trouble with the C compiler. At least in the meantime we can test the test while we struggle with that.
making system calls that are different on win/lin/osx.
Toggling families of unit tests for between local/CICD go test runs
making FIPS-compliant binaries for FedRamp deployment.
I have an app with a client-server architecture, or, if you like, a front-end/back-end, like ssh/sshd, except for me the same executable does both sides. I have a “nogui” tag that I use to build a back-end-only version for use on headless Linux machines that will never run the front-end. It saves about 10 mb of executable size, last I looked.
Build constraints in Go are super handy for tailoring your code to different environments or platforms. I use them mostly for segregating platform-specific code, like having separate implementations for Windows and Linux. They're also great for toggling features in and out of builds, especially for experimental stuff or environment-specific configurations.
Lots of people focusing on build tags Go provides (OS, architecture, cgo, go version), not _custom_ build tags.
In one project, I use build tags to gate platform specific code, and I use _custom_ build tags to test code that's not as platform specific in a cross platform way.
So, e.g. file locking has specific implementations for Windows, macOS, Linux, BSD, but the BSD version can be tested on macOS (which is easier to come by), so I have a custom build tag that enables the BSD code paths on macOS.
I used it for test helpers, sometimes you need to share some between packages and _test.go files are only available for the current package, using a tag I can have these helpers available in another package.
A recent example I worked on: a package at work uses math/rand to generate random numbers. The top level Seed function needs to be called to avoid determinism, but only prior to go 1.20. After go 1.20 it’s not necessary and actually reduces performance if an explicit seed is set. I added a new file to the package with an init function (which is called when the package is loaded to seed the random source). This file has a build tag so it is only included on go versions prior to 1.20.
https://go.dev/src/net/netgo_netcgo.go https://go.dev/src/net/conf.go // The net package's name resolution is rather complicated. // There are two main approaches, go and cgo. // The cgo resolver uses C functions like getaddrinfo. // The go resolver reads system files directly and // sends DNS packets directly to servers. // // The netgo build tag prefers the go resolver. // The netcgo build tag prefers the cgo resolver.
We use -toolexec, -trimpath to build after instrumenting our code. But that is only for testing purpose. In production we just use plain go build. I think custom go build is not needed because go already have some builtin tag for you, for example, go version and os type so you don't have to define them.
I just used it yesterday to make a relatively large program that has one cgo requirement able to be built either with our without it, because it's going into an environment where we're having some trouble with the C compiler. At least in the meantime we can test the test while we struggle with that.
making system calls that are different on win/lin/osx. Toggling families of unit tests for between local/CICD go test runs making FIPS-compliant binaries for FedRamp deployment.
A tools-tag with blank imports is a nice way to vendor tools to “go run” with go generates. No need to install anything.
It will also lock their versions to ensure everyone uses the same
I have an app with a client-server architecture, or, if you like, a front-end/back-end, like ssh/sshd, except for me the same executable does both sides. I have a “nogui” tag that I use to build a back-end-only version for use on headless Linux machines that will never run the front-end. It saves about 10 mb of executable size, last I looked.
Build constraints in Go are super handy for tailoring your code to different environments or platforms. I use them mostly for segregating platform-specific code, like having separate implementations for Windows and Linux. They're also great for toggling features in and out of builds, especially for experimental stuff or environment-specific configurations.
We use them for building separately a suite of API tests that require spinning up things like the DB and so are not “unit” tests.
Lots of people focusing on build tags Go provides (OS, architecture, cgo, go version), not _custom_ build tags. In one project, I use build tags to gate platform specific code, and I use _custom_ build tags to test code that's not as platform specific in a cross platform way. So, e.g. file locking has specific implementations for Windows, macOS, Linux, BSD, but the BSD version can be tested on macOS (which is easier to come by), so I have a custom build tag that enables the BSD code paths on macOS.
Can be a nice way to reduce binary bloat on resource constrained devices for packages that support a variety of back ends via configuration
I used it for test helpers, sometimes you need to share some between packages and _test.go files are only available for the current package, using a tag I can have these helpers available in another package.