Build constraints and vendoring
Build constraints and vendoring mode are tools you can use to fine-tune your build process. With build constraints, you define rules that determine which files are included in the package. By enabling vendoring mode, you ensure your application is built only with dependency packages stored within your project. This approach allows you to include a specific set of files in your package and use dependencies that you have locally modified or patched.
Build constraints
A build constraint, also known as a build tag, is a line comment that outlines the conditions under which a file is included in the package. These tags can specify requirements such as the operating system, architecture, Go version, compiler, cgo support, or other target system needs. In the example below, we declare that this file is for the target system meeting the following criteria:
// +build darwin,cgo linuxis the older syntax for build tags, still recognized in Go. It specifies two sets of conditions:darwin,cgo: Include in the build when compiling for thedarwinplatform (macOS) and whencgois enabled.cgoenables the inclusion of C code in Go programs.linux: Include when compiling for the Linux platform.
The space acts as an OR operator, meaning the file should be included for macOS with cgo enabled or for Linux.
//go:build (darwin && cgo) || linuxis the newer syntax for build tags, introduced in Go 1.17, using a more explicit boolean expression format:(darwin && cgo) || linux: The file should be included in the build for macOS with cgo enabled or for Linux, identical to the above condition.
GoLand can use these constraints to decide what files must be ignored during validation, resolving, and symbol suggestions. If the file does not satisfy the requirements of the target system, GoLand displays a notification.
In Go 1.17 and later, a //go:build directive requires a constraint, such as //go:build linux. If the constraint is empty, GoLand reports an error and offers a quick-fix to delete the comment. Add a constraint or remove the directive.
An empty legacy // +build directive has the same meaning as // +build ignore: the file is excluded unless you add ignore to Custom tags.
Configure build constraints for your project
The go build command in Go supports the use of custom tags through the -tags argument to conditionally compile files based on build constraints. These tags allow you to specify conditions under which files are included in the build process.
In your Go source files, you can define build constraints by placing a comment at the top of the file that includes the // +build or //go:build directive followed by the custom tags.
Open settings (Ctrl+Alt+S) and navigate to .
From drop-down lists, select expected values for the target system. If you have any custom tags, specify them in the Custom tags field (use a space between tags as a separator).
Click OK.
Using Go experiments
GoLand reads the experiments enabled by your Go toolchain and uses them to match goexperiment. build tags. Experiments enabled by default do not need a manual entry. Automatic detection requires a trusted project and a downloaded Go SDK.
Open settings by pressing Ctrl+Alt+S and navigate to .
To enable or disable an experiment, enter its name in Experiments without the
goexperiment.prefix. Separate names with commas. To disable an experiment supported by your toolchain, prefix its name withno, for example,noswissmap.GoLand passes these values to the Go toolchain. The toolchain's response determines which experiment build tags match your configuration.
Description of Build Tags fields
For more information about build tags or constraints, see Build constraints at pkg.go.dev.
Field | Values | Description |
|---|---|---|
Operating System |
| Selects the target operating system. The IDE passes the selected value to Go as In Go 1.19 and later, the |
Architecture |
| Selects the target CPU architecture. The IDE passes the selected value to Go as |
Go Version |
| Matches Go releases at or after the specified version. For example, |
Compiler |
| Selects a compiler when it is available. |
CGO Support |
| Matches whether cgo support is enabled. The IDE passes the selected setting to Go as |
Custom Tags | Custom tag names | Matches custom tags introduced by the For example, add |
Experiments | Experiment names | Enables or disables Go toolchain experiments. The IDE passes the selected values to Go as These values follow any |
Using multiple conditions for build constraints
The following table compares the legacy and current build constraint syntax when a condition uses AND and OR.
|
|
|---|---|
// +build darwin,cgo linux A comma (as a logical And) and a whitespace (as a logical Or) | //go:build (darwin && cgo) || linux The |
Vendoring
With the vendoring mode enabled, you build your application only with dependency packages that are stored inside your project under the vendor directory. In this mode, Go commands ignore dependency descriptions in go.mod and assume that the vendor directory holds the correct copies of dependencies. By default, when you use Go modules, the vendor directory is ignored during the build.
In Go 1.14 RC, automatic vendoring mode became a built-in Go feature. Starting from Go 1.14 RC, GoLand also enables automatic vendoring mode by default. You can disable vendoring per project, for example, when you have a monorepo containing the vendor folder used by another language.
You can control automatic vendoring by using the Enable vendoring support automatically checkbox. When the checkbox is selected, automatic vendoring is enabled. So, if you add the vendor directory to the module, the IDE uses it. If you remove the directory, GoLand uses the global Go Modules cache.
Toggle vendoring mode
Press Ctrl+Alt+S to open settings and then select .
Clear or select the Enable vendoring support automatically checkbox and click OK.