[Buildroot] [git commit] package/pkg-golang: simplify installing multiple binaries
Romain Naour
romain.naour at smile.fr
Wed Sep 10 11:08:48 UTC 2025
commit: https://git.buildroot.net/buildroot/commit/?id=fd4ece315109f327613ff9ca26d02894c73d8be6
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Currently, when a golang package defines multiple _BUILD_TARGETS, it has
to basically repeat the same list in its _INSTALL_BINS.
When a golang package defines multiple _BUILD_TARGETS, the pkg-golang
infra will forcibly use the basename (the notdir) of each target as the
name of the generated binary; there is no option to set a per-target
binary name.
However, the pkg-golang infra by default tries to install a binary named
after the package rawname. This forces packages to basically repeat the
same list as their _BUILD_TARGETS to override _INSTALL_BINS, when the
list of generated binaries is already known to the infra.
We change the pkg-golang infra to better cover such a case:
- if _BUILD_TARGET is '.' (the default), keep the current scheme:
install a single binary named after the package rwaname;
- if _BUILD_TARGET is not '.', and contains a single word, use the
notdir of the built target, but allow the user to override it with
_BIN_NAME (the current behaviour);
- otherwise (_BUILD_TARGETS is set to more than one word), do not
allow the user to set _BIN_NAME (it does not make sense), but set
_INSTALL_BINS by default to the notdir of _BUILD_TARGETS.
We still allow the user to set _INSTALL_BINS in the last case, to cover
the case for existing packages; those are going to be "fixed" in the
following commits.
We now consider that _INSTALL_BINS is an internal implementation details
that should no longer be exposed to the users, so we drop it from the
documentation; we rephrase the corresponding part for _BUILD_TARGETS.
Signed-off-by: Yann E. MORIN <yann.morin at orange.com>
Cc: Christian Stewart <christian at aperture.us>
Reviewed-by: Romain Naour <romain.naour at smile.fr>
Reviewed-by: Christian Stewart <christian at aperture.us>
Signed-off-by: Romain Naour <romain.naour at smile.fr>
---
docs/manual/adding-packages-golang.adoc | 28 ++++++++++++++--------------
package/pkg-golang.mk | 11 +++++++++--
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/docs/manual/adding-packages-golang.adoc b/docs/manual/adding-packages-golang.adoc
index 6de0916a83..21b6a122a9 100644
--- a/docs/manual/adding-packages-golang.adoc
+++ b/docs/manual/adding-packages-golang.adoc
@@ -94,20 +94,20 @@ therefore only use a few of them, or none.
defaults to +.+. We then have two cases:
** +FOO_BUILD_TARGETS+ is +.+. In this case, we assume only one binary
- will be produced, and that by default we name it after the package
- name. If that is not appropriate, the name of the produced binary
- can be overridden using +FOO_BIN_NAME+.
-
-** +FOO_BUILD_TARGETS+ is not +.+. In this case, we iterate over the
- values to build each target, and for each produced a binary that is
- the non-directory component of the target. For example if
- +FOO_BUILD_TARGETS = cmd/docker cmd/dockerd+ the binaries produced
- are +docker+ and +dockerd+.
-
-* +FOO_INSTALL_BINS+ can be used to pass the list of binaries that
- should be installed in +/usr/bin+ on the target. If
- +FOO_INSTALL_BINS+ is not specified, it defaults to the lower-case
- name of package.
+ will be built and installed, and by default we name it after the
+ package name; if that is not appropriate, the name of the binary can
+ be overridden using +FOO_BIN_NAME+.
+
+** +FOO_BUILD_TARGETS+ is not +.+. In this case, it is interpreted as a
+ space-separated list, and we iterate over the targets to build and
+ install a binary named after the non-directory component of the
+ target. For example if +FOO_BUILD_TARGETS = cmd/docker cmd/dockerd+,
+ the binaries built and installed are +docker+ and +dockerd+. If
+ +FOO_BUILD_TARGETS+ contains only one target, then it is possible to
+ override the built and installed binary by setting +FOO_BIN_NAME+,
+ as above; if +FOO_BUILD_TARGETS+ contains two or more targets, then
+ it is not possible to override the names of the installed binaries
+ (use a post-install hook for that).
With the Go infrastructure, all the steps required to build and
install the packages are already defined, and they generally work well
diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
index a4e8bd30cc..ff8d28aa7e 100644
--- a/package/pkg-golang.mk
+++ b/package/pkg-golang.mk
@@ -61,9 +61,16 @@ $(2)_BUILD_TARGETS ?= .
# after each build target building them (below in <pkg>_BUILD_CMDS).
ifeq ($$($(2)_BUILD_TARGETS),.)
$(2)_BIN_NAME ?= $$($(2)_RAWNAME)
+$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
+else ifeq ($$(words $$($(2)_BUILD_TARGETS)),1)
+$(2)_BIN_NAME ?= $$(notdir $$($(2)_BUILD_TARGETS))
+$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
+else
+ifneq ($$($(2)_BIN_NAME),)
+$$(error $(1) sets $(2)_BIN_NAME while there are multiple targets in $(2)_BUILD_TARGETS)
+endif
+$(2)_INSTALL_BINS ?= $$(notdir $$($(2)_BUILD_TARGETS))
endif
-
-$(2)_INSTALL_BINS ?= $$($(2)_RAWNAME)
# Source files in Go usually use an import path resolved around
# domain/vendor/software. We infer domain/vendor/software from the upstream URL
More information about the buildroot
mailing list