mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-08-23 15:54:21 -09:00
package/pkg-golang: simplify installing multiple binaries
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@orange.com>
Cc: Christian Stewart <christian@aperture.us>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Christian Stewart <christian@aperture.us>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This commit is contained in:
committed by
Romain Naour
parent
55bc78bc03
commit
fd4ece3151
@@ -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+.
|
||||
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, 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.
|
||||
** +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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user