2018-03-31 15:27:30 +02:00
|
|
|
################################################################################
|
|
|
|
|
# Golang package infrastructure
|
|
|
|
|
#
|
|
|
|
|
# This file implements an infrastructure that eases development of package .mk
|
|
|
|
|
# files for Go packages. It should be used for all packages that are written in
|
|
|
|
|
# go.
|
|
|
|
|
#
|
|
|
|
|
# See the Buildroot documentation for details on the usage of this
|
|
|
|
|
# infrastructure
|
|
|
|
|
#
|
|
|
|
|
#
|
|
|
|
|
# In terms of implementation, this golang infrastructure requires the .mk file
|
|
|
|
|
# to only specify metadata information about the package: name, version,
|
|
|
|
|
# download URL, etc.
|
|
|
|
|
#
|
|
|
|
|
# We still allow the package .mk file to override what the different steps are
|
|
|
|
|
# doing, if needed. For example, if <PKG>_BUILD_CMDS is already defined, it is
|
|
|
|
|
# used as the list of commands to perform to build the package, instead of the
|
|
|
|
|
# default golang behavior. The package can also define some post operation
|
|
|
|
|
# hooks.
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
GO_BIN = $(HOST_DIR)/bin/go
|
|
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
|
# inner-golang-package -- defines how the configuration, compilation and
|
|
|
|
|
# installation of a Go package should be done, implements a few hooks to tune
|
|
|
|
|
# the build process for Go specificities and calls the generic package
|
|
|
|
|
# infrastructure to generate the necessary make targets
|
|
|
|
|
#
|
|
|
|
|
# argument 1 is the lowercase package name
|
|
|
|
|
# argument 2 is the uppercase package name, including a HOST_ prefix for host
|
|
|
|
|
# packages
|
|
|
|
|
# argument 3 is the uppercase package name, without the HOST_ prefix for host
|
|
|
|
|
# packages
|
|
|
|
|
# argument 4 is the type (target or host)
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
define inner-golang-package
|
|
|
|
|
|
2018-11-25 10:19:48 +01:00
|
|
|
$(2)_BUILD_OPTS += \
|
|
|
|
|
-ldflags "$$($(2)_LDFLAGS)" \
|
2020-12-19 16:35:18 +01:00
|
|
|
-modcacherw \
|
2018-11-25 10:19:48 +01:00
|
|
|
-tags "$$($(2)_TAGS)" \
|
2019-12-07 20:57:07 +01:00
|
|
|
-trimpath \
|
package/pkg-golang: fix build with per-package directories
Build with per-package directory is broken, because go is not found in
the PATH, when trying to download and vendor a go package.
This is because FOO_DL_ENV contains $(HOST_GO_COMMON_ENV), which defines
the PATH as PATH=$(BR_PATH). This is correct, except this is expanded at
the time the golang-package macro is evaluated, which means PATH
contains the 'global' BR_PATH, i.e.: $(O)/host/bin:$(O)/host/sbin:...
However, with PPD, this does not yet exist at build time; only the
per-package host directory exists.
We want to have it expanded at the time the recipe is run, so like all
other variables, we need to $$-expand it.
At the same time, also $$-expand two other variables (even though those
are benign, it is better for consistency that they be $$-expanded).
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Anisse Astier <anisse@astier.eu>
Cc: Christian Stewart <christian@paral.in>
Reviewed-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-03-07 16:42:56 +01:00
|
|
|
-p $$(PARALLEL_JOBS)
|
2018-03-31 15:27:30 +02:00
|
|
|
|
2022-02-10 16:29:28 +01:00
|
|
|
# Target packages need the Go compiler on the host at download time (for
|
|
|
|
|
# vendoring), and at build and install time.
|
2020-12-19 16:35:18 +01:00
|
|
|
$(2)_DOWNLOAD_DEPENDENCIES += host-go
|
2022-02-10 16:29:28 +01:00
|
|
|
$(2)_DEPENDENCIES += host-go
|
2018-03-31 15:27:30 +02:00
|
|
|
|
|
|
|
|
$(2)_BUILD_TARGETS ?= .
|
|
|
|
|
|
package/pkg-golang: use 'build' instead of 'install'
So far, we were using the 'go install' mechanism to build a package
and have its binary installed in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH). This worked fine when
building on x86-64 for ARM, but failed when building on x86-64 for
x86-64 because the binaries were installed in $$($(2)_WORKSPACE)/bin/.
Instead of doing some complicated logic to guess whether Go is going
to put our binaries in $$($(2)_WORKSPACE)/bin/ or in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH), we revert back to using
"go build", as it was done before the introduction of the golang
package infrastructure. "go build" lets us pass explicitly the
destination path of the binary to be generated.
There's just one complexity with how to decide on the name of the
binary that should be produced, and we have two cases:
- <pkg>_BUILD_TARGETS is the default, i.e ".". In this case we assume
a single binary is produced by "go build", and we name if after the
lower case package name. We allow this to be overridden thanks to
<pkg>_BIN_NAME.
- <pkg>_BUILD_TARGETS is non-default, and typically contains
something like "foo bar" or "cmd/foo cmd/bar". In this case, we
assume the binaries to be produced are "foo" and "bar", i.e we take
the non-directory part of the build target to name the binaries.
Because we're using this -o option, we no longer need to explicitly
create the binary directory, it is done by "go build".
Fixes:
http://autobuild.buildroot.net/results/1f9cd7c48e8c8f41326632a9c0de83915d72c45b/
[Peter: use $(or instead of $(if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-01 13:51:35 +02:00
|
|
|
# If the build target is just ".", then we assume the binary to be
|
|
|
|
|
# produced is named after the package. If however, a build target has
|
|
|
|
|
# been specified, we assume that the binaries to be produced are named
|
|
|
|
|
# after each build target building them (below in <pkg>_BUILD_CMDS).
|
|
|
|
|
ifeq ($$($(2)_BUILD_TARGETS),.)
|
package/pkg-golang: default to rawname to install binaries
The default currently is to rely on the package name to decide what to
build and install if not specified by the caller. This works nice for
target packages, where a 'foo' package will by default build and
install a 'foo' executable.
However, for host packages, that will build and install a 'host-foo'
exzcutable, which is not really, even really not, what would be
expected.
We fix that by using the package raw name, i.e. the package name with
the host- prefix yanked away.
It is very improbable that there already are many host-golang packages in
the wild (in br2-external trees), but if there are, they would forcibly
define those variables to a sane value. This change is not incompatible, as
the values provided by packages take precedence; it's just that those
packages now carry superfluous, if innocuous, variable assignments.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-03-08 17:53:10 +01:00
|
|
|
$(2)_BIN_NAME ?= $$($(2)_RAWNAME)
|
package/pkg-golang: use 'build' instead of 'install'
So far, we were using the 'go install' mechanism to build a package
and have its binary installed in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH). This worked fine when
building on x86-64 for ARM, but failed when building on x86-64 for
x86-64 because the binaries were installed in $$($(2)_WORKSPACE)/bin/.
Instead of doing some complicated logic to guess whether Go is going
to put our binaries in $$($(2)_WORKSPACE)/bin/ or in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH), we revert back to using
"go build", as it was done before the introduction of the golang
package infrastructure. "go build" lets us pass explicitly the
destination path of the binary to be generated.
There's just one complexity with how to decide on the name of the
binary that should be produced, and we have two cases:
- <pkg>_BUILD_TARGETS is the default, i.e ".". In this case we assume
a single binary is produced by "go build", and we name if after the
lower case package name. We allow this to be overridden thanks to
<pkg>_BIN_NAME.
- <pkg>_BUILD_TARGETS is non-default, and typically contains
something like "foo bar" or "cmd/foo cmd/bar". In this case, we
assume the binaries to be produced are "foo" and "bar", i.e we take
the non-directory part of the build target to name the binaries.
Because we're using this -o option, we no longer need to explicitly
create the binary directory, it is done by "go build".
Fixes:
http://autobuild.buildroot.net/results/1f9cd7c48e8c8f41326632a9c0de83915d72c45b/
[Peter: use $(or instead of $(if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-01 13:51:35 +02:00
|
|
|
endif
|
2018-03-31 15:27:30 +02:00
|
|
|
|
package/pkg-golang: default to rawname to install binaries
The default currently is to rely on the package name to decide what to
build and install if not specified by the caller. This works nice for
target packages, where a 'foo' package will by default build and
install a 'foo' executable.
However, for host packages, that will build and install a 'host-foo'
exzcutable, which is not really, even really not, what would be
expected.
We fix that by using the package raw name, i.e. the package name with
the host- prefix yanked away.
It is very improbable that there already are many host-golang packages in
the wild (in br2-external trees), but if there are, they would forcibly
define those variables to a sane value. This change is not incompatible, as
the values provided by packages take precedence; it's just that those
packages now carry superfluous, if innocuous, variable assignments.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-03-08 17:53:10 +01:00
|
|
|
$(2)_INSTALL_BINS ?= $$($(2)_RAWNAME)
|
2018-03-31 15:27:30 +02:00
|
|
|
|
2020-08-29 11:28:37 +02:00
|
|
|
# Source files in Go usually use an import path resolved around
|
|
|
|
|
# domain/vendor/software. We infer domain/vendor/software from the upstream URL
|
|
|
|
|
# of the project.
|
package/pkg-golang: post-pone evaluation of variables
As explained in pkg-generic.mk, all variable references inside the
inner-xxx-package should use $$(...). Otherwise, they are evaluated
too early, and will not contain the expected value. In the content of
the pkg-golang infrastructure, the <pkg>_SRC_DOMAIN, <pkg>_SRC_VENDOR
and <pkg>_SRC_SOFTWARE variables were not properly escaping their
reference to the $$($(2)_SITE) variable.
This was not visible until now, as only target Go packages were
supported, where $(2)_SITE was always defined prior to this macro
being expanded. With the upcoming support of host Go packages, we need
to fix this, as $(2)_SITE may be defined later, inherited from
$(3)_SITE.
Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
[Thomas: rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-08-15 09:16:09 +02:00
|
|
|
$(2)_SRC_DOMAIN = $$(call domain,$$($(2)_SITE))
|
|
|
|
|
$(2)_SRC_VENDOR = $$(word 1,$$(subst /, ,$$(call notdomain,$$($(2)_SITE))))
|
|
|
|
|
$(2)_SRC_SOFTWARE = $$(word 2,$$(subst /, ,$$(call notdomain,$$($(2)_SITE))))
|
2018-03-31 15:27:30 +02:00
|
|
|
|
2020-08-29 11:28:37 +02:00
|
|
|
# $(2)_GOMOD is the root Go module path for the project, inferred if not set.
|
|
|
|
|
# If the go.mod file does not exist, one is written with this root path.
|
|
|
|
|
$(2)_GOMOD ?= $$($(2)_SRC_DOMAIN)/$$($(2)_SRC_VENDOR)/$$($(2)_SRC_SOFTWARE)
|
2018-03-31 15:27:30 +02:00
|
|
|
|
2020-08-29 11:28:37 +02:00
|
|
|
# Generate a go.mod file if it doesn't exist. Note: Go is configured
|
|
|
|
|
# to use the "vendor" dir and not make network calls.
|
|
|
|
|
define $(2)_GEN_GOMOD
|
|
|
|
|
if [ ! -f $$(@D)/go.mod ]; then \
|
|
|
|
|
printf "module $$($(2)_GOMOD)\n" > $$(@D)/go.mod; \
|
|
|
|
|
fi
|
2018-03-31 15:27:30 +02:00
|
|
|
endef
|
2020-08-29 11:28:37 +02:00
|
|
|
$(2)_POST_PATCH_HOOKS += $(2)_GEN_GOMOD
|
2018-03-31 15:27:30 +02:00
|
|
|
|
2020-12-19 16:35:18 +01:00
|
|
|
$(2)_DOWNLOAD_POST_PROCESS = go
|
2022-02-10 16:29:27 +01:00
|
|
|
$(2)_DL_ENV += \
|
package/pkg-golang: fix build with per-package directories
Build with per-package directory is broken, because go is not found in
the PATH, when trying to download and vendor a go package.
This is because FOO_DL_ENV contains $(HOST_GO_COMMON_ENV), which defines
the PATH as PATH=$(BR_PATH). This is correct, except this is expanded at
the time the golang-package macro is evaluated, which means PATH
contains the 'global' BR_PATH, i.e.: $(O)/host/bin:$(O)/host/sbin:...
However, with PPD, this does not yet exist at build time; only the
per-package host directory exists.
We want to have it expanded at the time the recipe is run, so like all
other variables, we need to $$-expand it.
At the same time, also $$-expand two other variables (even though those
are benign, it is better for consistency that they be $$-expanded).
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Anisse Astier <anisse@astier.eu>
Cc: Christian Stewart <christian@paral.in>
Reviewed-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-03-07 16:42:56 +01:00
|
|
|
$$(HOST_GO_COMMON_ENV) \
|
2022-03-07 16:43:13 +01:00
|
|
|
GOPROXY=direct
|
2020-12-19 16:35:18 +01:00
|
|
|
|
|
|
|
|
# Due to vendoring, it is pretty likely that not all licenses are
|
|
|
|
|
# listed in <pkg>_LICENSE.
|
|
|
|
|
$(2)_LICENSE += , vendored dependencies licenses probably not listed
|
|
|
|
|
|
package/pkg-golang: use 'build' instead of 'install'
So far, we were using the 'go install' mechanism to build a package
and have its binary installed in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH). This worked fine when
building on x86-64 for ARM, but failed when building on x86-64 for
x86-64 because the binaries were installed in $$($(2)_WORKSPACE)/bin/.
Instead of doing some complicated logic to guess whether Go is going
to put our binaries in $$($(2)_WORKSPACE)/bin/ or in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH), we revert back to using
"go build", as it was done before the introduction of the golang
package infrastructure. "go build" lets us pass explicitly the
destination path of the binary to be generated.
There's just one complexity with how to decide on the name of the
binary that should be produced, and we have two cases:
- <pkg>_BUILD_TARGETS is the default, i.e ".". In this case we assume
a single binary is produced by "go build", and we name if after the
lower case package name. We allow this to be overridden thanks to
<pkg>_BIN_NAME.
- <pkg>_BUILD_TARGETS is non-default, and typically contains
something like "foo bar" or "cmd/foo cmd/bar". In this case, we
assume the binaries to be produced are "foo" and "bar", i.e we take
the non-directory part of the build target to name the binaries.
Because we're using this -o option, we no longer need to explicitly
create the binary directory, it is done by "go build".
Fixes:
http://autobuild.buildroot.net/results/1f9cd7c48e8c8f41326632a9c0de83915d72c45b/
[Peter: use $(or instead of $(if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-01 13:51:35 +02:00
|
|
|
# Build step. Only define it if not already defined by the package .mk
|
|
|
|
|
# file.
|
2018-03-31 15:27:30 +02:00
|
|
|
ifndef $(2)_BUILD_CMDS
|
2019-02-06 14:23:58 +01:00
|
|
|
ifeq ($(4),target)
|
2019-06-10 17:40:07 +02:00
|
|
|
|
|
|
|
|
ifeq ($(BR2_STATIC_LIBS),y)
|
|
|
|
|
$(2)_LDFLAGS += -extldflags '-static'
|
|
|
|
|
endif
|
|
|
|
|
|
2019-02-06 14:23:58 +01:00
|
|
|
# Build package for target
|
2018-03-31 15:27:30 +02:00
|
|
|
define $(2)_BUILD_CMDS
|
|
|
|
|
$$(foreach d,$$($(2)_BUILD_TARGETS),\
|
2020-08-29 11:28:37 +02:00
|
|
|
cd $$(@D); \
|
2020-08-29 11:15:49 +02:00
|
|
|
$$(HOST_GO_TARGET_ENV) \
|
2018-03-31 15:27:30 +02:00
|
|
|
$$($(2)_GO_ENV) \
|
package/pkg-golang: use 'build' instead of 'install'
So far, we were using the 'go install' mechanism to build a package
and have its binary installed in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH). This worked fine when
building on x86-64 for ARM, but failed when building on x86-64 for
x86-64 because the binaries were installed in $$($(2)_WORKSPACE)/bin/.
Instead of doing some complicated logic to guess whether Go is going
to put our binaries in $$($(2)_WORKSPACE)/bin/ or in
$$($(2)_WORKSPACE)/bin/linux_$$(GO_GOARCH), we revert back to using
"go build", as it was done before the introduction of the golang
package infrastructure. "go build" lets us pass explicitly the
destination path of the binary to be generated.
There's just one complexity with how to decide on the name of the
binary that should be produced, and we have two cases:
- <pkg>_BUILD_TARGETS is the default, i.e ".". In this case we assume
a single binary is produced by "go build", and we name if after the
lower case package name. We allow this to be overridden thanks to
<pkg>_BIN_NAME.
- <pkg>_BUILD_TARGETS is non-default, and typically contains
something like "foo bar" or "cmd/foo cmd/bar". In this case, we
assume the binaries to be produced are "foo" and "bar", i.e we take
the non-directory part of the build target to name the binaries.
Because we're using this -o option, we no longer need to explicitly
create the binary directory, it is done by "go build".
Fixes:
http://autobuild.buildroot.net/results/1f9cd7c48e8c8f41326632a9c0de83915d72c45b/
[Peter: use $(or instead of $(if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-01 13:51:35 +02:00
|
|
|
$$(GO_BIN) build -v $$($(2)_BUILD_OPTS) \
|
2018-04-01 13:51:36 +02:00
|
|
|
-o $$(@D)/bin/$$(or $$($(2)_BIN_NAME),$$(notdir $$(d))) \
|
2020-08-29 11:28:37 +02:00
|
|
|
$$($(2)_GOMOD)/$$(d)
|
2018-03-31 15:27:30 +02:00
|
|
|
)
|
|
|
|
|
endef
|
2019-02-06 14:23:58 +01:00
|
|
|
else
|
|
|
|
|
# Build package for host
|
|
|
|
|
define $(2)_BUILD_CMDS
|
|
|
|
|
$$(foreach d,$$($(2)_BUILD_TARGETS),\
|
2020-08-29 11:28:37 +02:00
|
|
|
cd $$(@D); \
|
2020-08-29 11:15:49 +02:00
|
|
|
$$(HOST_GO_HOST_ENV) \
|
2019-02-06 14:23:58 +01:00
|
|
|
$$($(2)_GO_ENV) \
|
|
|
|
|
$$(GO_BIN) build -v $$($(2)_BUILD_OPTS) \
|
|
|
|
|
-o $$(@D)/bin/$$(or $$($(2)_BIN_NAME),$$(notdir $$(d))) \
|
2020-08-29 11:28:37 +02:00
|
|
|
$$($(2)_GOMOD)/$$(d)
|
2019-02-06 14:23:58 +01:00
|
|
|
)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
2018-03-31 15:27:30 +02:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Target installation step. Only define it if not already defined by the
|
|
|
|
|
# package .mk file.
|
|
|
|
|
ifndef $(2)_INSTALL_TARGET_CMDS
|
|
|
|
|
define $(2)_INSTALL_TARGET_CMDS
|
|
|
|
|
$$(foreach d,$$($(2)_INSTALL_BINS),\
|
package/pkg-golang: fix build with per-package directories
Build with per-package directory is broken, because go is not found in
the PATH, when trying to download and vendor a go package.
This is because FOO_DL_ENV contains $(HOST_GO_COMMON_ENV), which defines
the PATH as PATH=$(BR_PATH). This is correct, except this is expanded at
the time the golang-package macro is evaluated, which means PATH
contains the 'global' BR_PATH, i.e.: $(O)/host/bin:$(O)/host/sbin:...
However, with PPD, this does not yet exist at build time; only the
per-package host directory exists.
We want to have it expanded at the time the recipe is run, so like all
other variables, we need to $$-expand it.
At the same time, also $$-expand two other variables (even though those
are benign, it is better for consistency that they be $$-expanded).
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Anisse Astier <anisse@astier.eu>
Cc: Christian Stewart <christian@paral.in>
Reviewed-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-03-07 16:42:56 +01:00
|
|
|
$$(INSTALL) -D -m 0755 $$(@D)/bin/$$(d) $$(TARGET_DIR)/usr/bin/$$(d)
|
2018-03-31 15:27:30 +02:00
|
|
|
)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
|
2019-02-06 14:23:58 +01:00
|
|
|
# Host installation step
|
|
|
|
|
ifndef $(2)_INSTALL_CMDS
|
|
|
|
|
define $(2)_INSTALL_CMDS
|
|
|
|
|
$$(foreach d,$$($(2)_INSTALL_BINS),\
|
package/pkg-golang: fix build with per-package directories
Build with per-package directory is broken, because go is not found in
the PATH, when trying to download and vendor a go package.
This is because FOO_DL_ENV contains $(HOST_GO_COMMON_ENV), which defines
the PATH as PATH=$(BR_PATH). This is correct, except this is expanded at
the time the golang-package macro is evaluated, which means PATH
contains the 'global' BR_PATH, i.e.: $(O)/host/bin:$(O)/host/sbin:...
However, with PPD, this does not yet exist at build time; only the
per-package host directory exists.
We want to have it expanded at the time the recipe is run, so like all
other variables, we need to $$-expand it.
At the same time, also $$-expand two other variables (even though those
are benign, it is better for consistency that they be $$-expanded).
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Anisse Astier <anisse@astier.eu>
Cc: Christian Stewart <christian@paral.in>
Reviewed-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2022-03-07 16:42:56 +01:00
|
|
|
$$(INSTALL) -D -m 0755 $$(@D)/bin/$$(d) $$(HOST_DIR)/bin/$$(d)
|
2019-02-06 14:23:58 +01:00
|
|
|
)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
|
2018-03-31 15:27:30 +02:00
|
|
|
# Call the generic package infrastructure to generate the necessary make
|
|
|
|
|
# targets
|
|
|
|
|
$(call inner-generic-package,$(1),$(2),$(3),$(4))
|
|
|
|
|
|
|
|
|
|
endef # inner-golang-package
|
|
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
|
# golang-package -- the target generator macro for Go packages
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
golang-package = $(call inner-golang-package,$(pkgname),$(call UPPERCASE,$(pkgname)),$(call UPPERCASE,$(pkgname)),target)
|
2019-02-06 14:23:58 +01:00
|
|
|
host-golang-package = $(call inner-golang-package,host-$(pkgname),$(call UPPERCASE,host-$(pkgname)),$(call UPPERCASE,$(pkgname)),host)
|
