Debian::Debhelper::Buildsystem::golang(3pm) | User Contributed Perl Documentation | Debian::Debhelper::Buildsystem::golang(3pm) |
dh-golang -- debhelper build system class for Go packages
The dh-golang package provides a build system for debhelper which can be used by adding dh-sequence-golang to the package build dependencies, and passing the following options to dh:
%: dh $@ --builddirectory=_build --buildsystem=golang
Starting with debhelper 13.4 (a versioned build dependency is currently required), the build system is automatically detected, and the following is enough:
%: dh $@ --builddirectory=_build
Starting with debhelper compatibility level 14, the build directory defaults to _build, and the following is enough:
%: dh $@
Here is a brief description of how the golang build system implements each debhelper build system stage:
Example (in "debian/rules"):
override_dh_auto_install: dh_auto_install -- --no-source
Example (in "debian/rules"):
override_dh_auto_install: dh_auto_install -- --no-binaries
Note: instead of using this option (which was added for symmetry with "--no-source"), consider not building unwanted binaries in the first place to save CPU time on our build daemons; see "DH_GOLANG_EXCLUDES".
"DH_GOPKG" is automatically set to the value of the first import path of the "XS-Go-Import-Path" "debian/control" field, which can contain several comma-separated import paths.
Example (in "debian/control"):
XS-Go-Import-Path: github.com/go-mgo/mgo, gopkg.in/mgo.v2, labix.org/v2/mgo, launchpad.net/mgo
"DH_GOPKG" is set by dh-golang, and as a consequence it is not present in the "debian/rules" environment. If you need to use the Go package name in the "debian/rules" file, you must define it yourself.
Example (in "debian/rules"):
export DH_GOPKG := github.com/go-mgo/mgo
Historical note: before the "XS-Go-Import-Path" field was introduced, we used to set "DH_GOPKG" in "debian/rules". When you encounter such a package, please convert it by moving the value from "debian/rules" to "debian/control". It is preferable to use the "debian/control" field because it is machine-readable and picked up/used by various Debian infrastructure tools, whereas "debian/rules" is very hard to parse.
Example (in "debian/rules"):
export DH_GOLANG_INSTALL_EXTRA := example.toml marshal_test.toml
Example (in "debian/rules"):
export DH_GOLANG_INSTALL_ALL := 1
Note: prefer the "DH_GOLANG_INSTALL_EXTRA" environment variable because it is self-documenting and future-proof: when using "DH_GOLANG_INSTALL_ALL", readers of your package cannot easily tell which extra files in particular need to be installed, and newer upstream versions might result in unexpected extra files.
The default value matches all Go packages within the source, which is usually desired, but you might need to exclude example programs, for which you should use the "DH_GOLANG_EXCLUDES" environment variable.
Example (in "debian/rules"):
# Install only programs for end users, the also-included Go packages are not # yet mature enough to be shipped for other packages to consume (despite what # upstream claims). export DH_GOLANG_BUILDPKG := github.com/debian/ratt/cmd/...
Please note that with DH_COMPAT level inferior or equal to 11, the default is to only exclude pattern from the build target. (see "DH_GOLANG_EXCLUDES_ALL" below)
Example (in "debian/rules"):
# We want to build only the library packages themselves, not the accompanying # example binaries. export DH_GOLANG_EXCLUDES := examples/
# We want to ship only the library packages themselves in the go source, not # the accompanying example binaries. export DH_GOLANG_EXCLUDES := examples/ export DH_GOLANG_EXCLUDES_ALL := 1
It is convention in the Go community to commit all "go generate" artifacts to version control, so re-generating these artifacts is usually not required.
Depending on what the Go package in question uses "go generate" for, you may want to enable "DH_GOLANG_GO_GENERATE":
Example (in "debian/rules"):
export DH_GOLANG_GO_GENERATE := 1
Note: this option should default to true, but it was introduced after dh-golang was already widely used, and nobody made the transition happen yet (i.e. inspect and possibly fix any resulting breakages).
2023-08-29 | perl v5.36.0 |