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
|
|
|
|
|
|
|
|
|
|
# We pass an empty GOBIN, otherwise "go install: cannot install
|
|
|
|
|
# cross-compiled binaries when GOBIN is set"
|
|
|
|
|
GO_TARGET_ENV = \
|
|
|
|
|
$(HOST_GO_TARGET_ENV) \
|
2018-04-02 15:41:45 +02:00
|
|
|
PATH=$(BR_PATH) \
|
2018-03-31 15:27:30 +02:00
|
|
|
GOBIN= \
|
|
|
|
|
CGO_ENABLED=$(HOST_GO_CGO_ENABLED)
|
|
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
|
# 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)
|
|
|
|
|
#
|
|
|
|
|
# NOTE Only type target is supported at the moment
|
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
define inner-golang-package
|
|
|
|
|
|
|
|
|
|
$(2)_WORKSPACE ?= _gopath
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_STATIC_LIBS),y)
|
|
|
|
|
$(2)_LDFLAGS += -extldflags '-static'
|
|
|
|
|
endif
|
|
|
|
|
|
2018-11-25 10:19:48 +01:00
|
|
|
$(2)_BUILD_OPTS += \
|
|
|
|
|
-ldflags "$$($(2)_LDFLAGS)" \
|
|
|
|
|
-tags "$$($(2)_TAGS)" \
|
|
|
|
|
-p $(PARALLEL_JOBS)
|
2018-03-31 15:27:30 +02:00
|
|
|
|
|
|
|
|
# Target packages need the Go compiler on the host.
|
|
|
|
|
$(2)_DEPENDENCIES += host-go
|
|
|
|
|
|
|
|
|
|
$(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),.)
|
|
|
|
|
$(2)_BIN_NAME ?= $(1)
|
|
|
|
|
endif
|
2018-03-31 15:27:30 +02:00
|
|
|
|
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
|
|
|
$(2)_INSTALL_BINS ?= $(1)
|
2018-03-31 15:27:30 +02:00
|
|
|
|
|
|
|
|
# Source files in Go should be extracted in a precise folder in the hierarchy
|
|
|
|
|
# of GOPATH. It usually resolves around domain/vendor/software. By default, we
|
|
|
|
|
# derive domain/vendor/software from the upstream URL of the project, but we
|
|
|
|
|
# allow $(2)_SRC_SUBDIR to be overridden if needed.
|
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
|
|
|
|
|
|
|
|
$(2)_SRC_SUBDIR ?= $$($(2)_SRC_DOMAIN)/$$($(2)_SRC_VENDOR)/$$($(2)_SRC_SOFTWARE)
|
|
|
|
|
$(2)_SRC_PATH = $$(@D)/$$($(2)_WORKSPACE)/src/$$($(2)_SRC_SUBDIR)
|
|
|
|
|
|
|
|
|
|
# Configure step. Only define it if not already defined by the package .mk
|
|
|
|
|
# file.
|
|
|
|
|
ifndef $(2)_CONFIGURE_CMDS
|
|
|
|
|
define $(2)_CONFIGURE_CMDS
|
|
|
|
|
mkdir -p $$(dir $$($(2)_SRC_PATH))
|
|
|
|
|
ln -sf $$(@D) $$($(2)_SRC_PATH)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
|
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
|
|
|
|
|
define $(2)_BUILD_CMDS
|
|
|
|
|
$$(foreach d,$$($(2)_BUILD_TARGETS),\
|
|
|
|
|
cd $$($(2)_SRC_PATH); \
|
|
|
|
|
$$(GO_TARGET_ENV) \
|
|
|
|
|
GOPATH="$$(@D)/$$($(2)_WORKSPACE)" \
|
|
|
|
|
$$($(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))) \
|
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
|
|
|
./$$(d)
|
2018-03-31 15:27:30 +02:00
|
|
|
)
|
|
|
|
|
endef
|
|
|
|
|
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),\
|
2018-04-01 13:51:36 +02:00
|
|
|
$(INSTALL) -D -m 0755 $$(@D)/bin/$$(d) $(TARGET_DIR)/usr/bin/$$(d)
|
2018-03-31 15:27:30 +02:00
|
|
|
)
|
|
|
|
|
endef
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# 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)
|
