package/pkg-cargo: allow packages to define download environment
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH v2 1/5 package/pkg-cargo: allow packages to define download environment
From: "Yann E. MORIN" <[email protected]>
Currently, the cargo infrastructure forcibly sets the package _DL_ENV variable, instead of appending to it, which prevents packages from providing their own download environment variables.
We fix that by using an append-assignment.
Note: when introduced, that variable was explicitly not documented, and is supposed to only be used by packages infrastructures. However, that variable exists, and it can be (ab)used by br2-external packages (most probably to ill effects, but heh!). We anyway leave it undocumented, like _ROOTFS_PRE_CMD_HOOKS.
--- package/pkg-cargo.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/pkg-cargo.mk +1 -1
@@ -69,7 +69,7 @@ define inner-cargo-package $(2)_DOWNLOAD_DEPENDENCIES += host-rustc $(2)_DOWNLOAD_POST_PROCESS = cargo -$(2)_DL_ENV = CARGO_HOME=$$(HOST_DIR)/share/cargo +$(2)_DL_ENV += CARGO_HOME=$$(HOST_DIR)/share/cargo # Due to vendoring, it is pretty likely that not all licenses are # listed in <pkg>_LICENSE.
Signature · 20 lines
2.25.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 8 lines · On Wed, 9 Feb 2022 17:08:43 +0100 <[email protected]> wrote:
From: "Yann E. MORIN" <[email protected]>
Currently, the cargo infrastructure forcibly sets the package
_DL_ENVvariable, instead of appending to it, which prevents packages from providing their own download environment variables.We fix that by using an append-assignment.
Quoted 8 lines
Note: when introduced, that variable was explicitly not documented, and is supposed to only be used by packages infrastructures. However, that variable exists, and it can be (ab)used by br2-external packages (most probably to ill effects, but heh!). We anyway leave it undocumented, like
_ROOTFS_PRE_CMD_HOOKS.Signed-off-by Yann E. MORIN <[email protected]>Cc Thomas Petazzoni <[email protected]>
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 3 lines · On Wed, 9 Feb 2022 17:08:43 +0100 <[email protected]> wrote:
$(2)_DOWNLOAD_POST_PROCESS = cargo
-$(2)_DL_ENV = CARGO_HOME=$$(HOST_DIR)/share/cargo +$(2)_DL_ENV += CARGO_HOME=$$(HOST_DIR)/share/cargo
But, but, then, how is:
PYTHON_CRYPTOGRAPHY_DL_ENV = \
BR_CARGO_MANIFEST_PATH=src/rust/Cargo.toml
currently working?
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Thomas, All,
On 2022-02-09 20:52 +0100, Thomas Petazzoni via buildroot spake thusly:
Quoted 6 lines
Quoted 3 lines · On Wed, 9 Feb 2022 17:08:43 +0100 <[email protected]> wrote:
$(2)_DOWNLOAD_POST_PROCESS = cargo
-$(2)_DL_ENV = CARGO_HOME=$$(HOST_DIR)/share/cargo +$(2)_DL_ENV += CARGO_HOME=$$(HOST_DIR)/share/cargo
Quoted 6 lines
But, but, then, how is:
PYTHON_CRYPTOGRAPHY_DL_ENV= \
BR_CARGO_MANIFEST_PATH=src/rust/Cargo.tomlcurrently working?
Because, its the name implies, it is a python-package, not a cargo-package.
Yeah, I got puzzled too. ;-)
Regards,
Yann E. MORIN.
Signature · 10 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 11 lines · On Wed, 9 Feb 2022 21:55:27 +0100 "Yann E. MORIN" <[email protected]>…
Quoted 6 lines
But, but, then, how is:
PYTHON_CRYPTOGRAPHY_DL_ENV= \
BR_CARGO_MANIFEST_PATH=src/rust/Cargo.tomlcurrently working?
Because, its the name implies, it is a python-package, not a cargo-package.
Yeah, I got puzzled too. ;-)
Aah, yes. Indeed. A python-package that builds Rust stuff. I wonder how it's possible for me to forget this, after having spent so many hours on this particular package! :-)
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v2 2/5 package/pkg-cargo: allow building in a sub-directory
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
Some packages have their rust sources as a sub-directory, rather than at the root of the source tree.
Do like we do for autotools-package, and use the package's _SRCDIR rather than the top-level directory $(@D).
Additionally, in such a situation, it is more than probable that the Cargo.toml is also present in that sub-directory, so use that when vendoring the package, unless the package took extra precautions to specify an alternate location.
---
Changes v1 -> v2:
- fix conditional (inverted logic)
- fix syntax in conditional (missing comma)
--- package/pkg-cargo.mk | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
package/pkg-cargo.mk +12 -4
@@ -71,6 +71,14 @@ $(2)_DOWNLOAD_DEPENDENCIES += host-rustc $(2)_DOWNLOAD_POST_PROCESS = cargo $(2)_DL_ENV += CARGO_HOME=$$(HOST_DIR)/share/cargo +# If building in a sub directory, use that to find the Cargo.toml, unless +# the package already provided its location. +ifneq ($$($(2)_SUBDIR),) +ifeq ($$(filter BR_CARGO_MANIFEST_PATH=%,$$($(2)_DL_ENV)),) +$(2)_DL_ENV += BR_CARGO_MANIFEST_PATH=$$($(2)_SUBDIR)/Cargo.toml +endif +endif + # Due to vendoring, it is pretty likely that not all licenses are # listed in <pkg>_LICENSE. $(2)_LICENSE += , vendored dependencies licenses probably not listed
@@ -97,7 +105,7 @@ $(2)_LICENSE += , vendored dependencies licenses probably not listed ifndef $(2)_BUILD_CMDS ifeq ($(4),target) define $(2)_BUILD_CMDS - cd $$(@D) && \ + cd $$($$(PKG)_SRCDIR) && \ $$(TARGET_MAKE_ENV) \ $$(TARGET_CONFIGURE_OPTS) \ $$(PKG_CARGO_ENV) \
@@ -111,7 +119,7 @@ define $(2)_BUILD_CMDS endef else # ifeq ($(4),target) define $(2)_BUILD_CMDS - cd $$(@D) && \ + cd $$($$(PKG)_SRCDIR) && \ $$(HOST_MAKE_ENV) \ RUSTFLAGS="$$(addprefix -C link-args=,$$(HOST_LDFLAGS))" \ $$(HOST_CONFIGURE_OPTS) \
@@ -133,7 +141,7 @@ endif # ifndef $(2)_BUILD_CMDS # ifndef $(2)_INSTALL_TARGET_CMDS define $(2)_INSTALL_TARGET_CMDS - cd $$(@D) && \ + cd $$($$(PKG)_SRCDIR) && \ $$(TARGET_MAKE_ENV) \ $$(TARGET_CONFIGURE_OPTS) \ $$(PKG_CARGO_ENV) \
@@ -152,7 +160,7 @@ endif ifndef $(2)_INSTALL_CMDS define $(2)_INSTALL_CMDS - cd $$(@D) && \ + cd $$($$(PKG)_SRCDIR) && \ $$(HOST_MAKE_ENV) \ RUSTFLAGS="$$(addprefix -C link-args=,$$(HOST_LDFLAGS))" \ $$(HOST_CONFIGURE_OPTS) \
Signature · 20 lines
2.25.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/5 v2] package/pkg-cargo: allow building in a sub-directory
package/pkg-cargo.mk $(2)_DOWNLOAD_DEPENDENCIES += host-rustc · line 78
Quoted 5 lines · On Wed, 9 Feb 2022 17:08:44 +0100 <[email protected]> wrote:
package/pkg-cargo.mk +5
-0+# If building in a sub directory, use that to find the Cargo.toml, unless +# the package already provided its location. +ifneq ($$($(2)_SUBDIR),) +ifeq ($$(filter BR_CARGO_MANIFEST_PATH=%,$$($(2)_DL_ENV)),) +$(2)_DL_ENV += BR_CARGO_MANIFEST_PATH=$$($(2)_SUBDIR)/Cargo.toml
I find that a bit "meh". Should we have an explicit package variable that tells the location of the Cargo.toml, instead of directly have packages pass this "magic" BR_CARGO_MANIFEST_PATH variable ?
Should $(2)_SUBDIR be documented for the cargo-package infra in the documentation ?
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 2/5 v2] package/pkg-cargo: allow building in a sub-directory
Thomas, All,
On 2022-02-09 20:54 +0100, Thomas Petazzoni spake thusly:
Quoted 9 lines
package/pkg-cargo.mk $(2)_DOWNLOAD_DEPENDENCIES += host-rustc · line 78
Quoted 5 lines · On Wed, 9 Feb 2022 17:08:44 +0100 <[email protected]> wrote:
package/pkg-cargo.mk +5
-0+# If building in a sub directory, use that to find the Cargo.toml, unless +# the package already provided its location. +ifneq ($$($(2)_SUBDIR),) +ifeq ($$(filter BR_CARGO_MANIFEST_PATH=%,$$($(2)_DL_ENV)),) +$(2)_DL_ENV += BR_CARGO_MANIFEST_PATH=$$($(2)_SUBDIR)/Cargo.tomlI find that a bit "meh".
I too am not fond of it, to be honest... But I am not a rust/cargo expert, by far, I wanted not to break any existing setup.
However, the cargo infra is brand new, and BR_CARGO_MANIFEST_PATH was not even advertised either, so we should probably not have to expect any package to actually use it already.
Quoted 3 lines
Should we have an explicit package variable
that tells the location of the Cargo.toml, instead of directly have packages pass this "magic"BR_CARGO_MANIFEST_PATHvariable ?
I was wondering if that would even make sense to have a different _SUBDIR and BR_CARGO_MANIFEST_PATH to begin with?
We have a package here that seems to be in such a situation, though:
https://github.com/Orange-OpenSource/its-client
The Cargo.toml is in rust/ but we need to do the build in rust/its-client/ ("cargo build" works perfectly well with a virtual workspace, like is used here, but "cargo install" refuses to work, muahaha...)
Still, because of a missing Cargo.lock in that package, vendoring by Buildroot does not work eother (we'll fix that later).
So, for now, I suggest we just expect that BR_CARGO_MANIFEST_PATH is the same as _SUBDIR, and thus the conditional assignment is not needed.
If in the future we do have an actual, working situation where they differ, then we may add the necessary infra, seems like a plan?
In the meantime, I'll respin the series with the ugly conditional removed.
Quoted 2 lines
Should $(2)_SUBDIR be documented for the cargo-package infra in the documentation ?
It is not documented for any of the other infras that make use of it (autotools, cmake, python, etc...).
The only mention of _SUBDIR in the manual is about _SUBDIRS (plural) for the kernel-module sub-infra.
Thanks for the review!
Regards,
Yann E. MORIN.
Quoted 5 lines
Thomas
Signature · 3 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com
Signature · 26 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
A message that is not in the archive (sent off-list or not yet received): 20220210150850.GA2599@tl-lnx-nyma7486
Re: [Buildroot] [PATCH 2/5 v2] package/pkg-cargo: allow building in a sub-directory
Thomas, Alll,
On 2022-02-10 16:08 +0100, MORIN Yann INNOV/IT-S spake thusly:
Quoted 7 lines
On 2022-02-09 20:54 +0100, Thomas Petazzoni spake thusly:
Quoted 2 lines
Should $(2)_SUBDIR be documented for the cargo-package infra in the documentation ?
It is not documented for any of the other infras that make use of it (autotools, cmake, python, etc...).
The only mention of_SUBDIRin the manual is about_SUBDIRS(plural) for the kernel-module sub-infra.
Scratch that, I seem to be unable to do a proper search in a webpage... :-(
I'll add it to the cargo part of the manual.
Cordialement,
Yann E. MORIN.
Signature · 26 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v2 3/5 package/pkg-cargo: host-rustc is also a build dependency
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
Currently, host-rustc is a download dependency, because we need cargo for the vendoring during the downlaod step.
However, when using a package in override-srcdir, there is no download step, so host-rustc is not pulled in as a dependency which breaks running the build of a single pcakge from scratch:
$ make clean
$ make my-rust-package
[...]
[...] cargo build --offline --release --manifest-path Cargo.toml --locked
/bin/sh: cargo: command not foundWe fix that by adding host-rustc as a standard dependency too.
--- package/pkg-cargo.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
package/pkg-cargo.mk +3 -1
@@ -65,8 +65,10 @@ HOST_PKG_CARGO_ENV = \ define inner-cargo-package -# We need host-rustc to run cargo +# We need host-rustc to run cargo at download time (for vendoring), +# and at build and install time. $(2)_DOWNLOAD_DEPENDENCIES += host-rustc +$(2)_DEPENDENCIES += host-rustc $(2)_DOWNLOAD_POST_PROCESS = cargo $(2)_DL_ENV += CARGO_HOME=$$(HOST_DIR)/share/cargo
Signature · 20 lines
2.25.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 3/5 v2] package/pkg-cargo: host-rustc is also a build dependency
Quoted 4 lines · On Wed, 9 Feb 2022 17:08:45 +0100 <[email protected]> wrote:
From: "Yann E. MORIN" <[email protected]>
Currently, host-rustc is a download dependency, because we need cargo for the vendoring during the downlaod step.
^^^^^^^^ download
Quoted 3 lines
However, when using a package in override-srcdir, there is no download step, so host-rustc is not pulled in as a dependency which breaks running the build of a single pcakge from scratch:
^^^^^^ package
Quoted 10 lines
$ make clean $ make my-rust-package [...] [...] cargo build --offline --release --manifest-path Cargo.toml --locked /bin/sh: cargo: command not foundWe fix that by adding host-rustc as a standard dependency too.
Signed-off-by Yann E. MORIN <[email protected]>Cc Thomas Petazzoni <[email protected]>
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v2 4/5 package/pkg-golang: allow packages to define download environment
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
Currently, the golang infrastructure forcibly sets the package _DL_ENV variable, instead of appending to it, which prevents packages from providing their own download environment variables.
We fix that by using an append-assignment.
Note: when introduced, that variable was explicitly not documented, and is supposed to only be used by packages infrastructures. However, that variable exists, and it can be (ab)used by br2-external packages (most probably to ill effects, but heh!). We anyway leave it undocumented, like _ROOTFS_PRE_CMD_HOOKS.
--- package/pkg-golang.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
package/pkg-golang.mk +1 -1
@@ -83,7 +83,7 @@ endef $(2)_POST_PATCH_HOOKS += $(2)_GEN_GOMOD $(2)_DOWNLOAD_POST_PROCESS = go -$(2)_DL_ENV = \ +$(2)_DL_ENV += \ $(HOST_GO_COMMON_ENV) \ GOPROXY=direct \ BR_GOMOD=$$($(2)_GOMOD)
Signature · 20 lines
2.25.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 4/5 v2] package/pkg-golang: allow packages to define download environment
Quoted 14 lines · On Wed, 9 Feb 2022 17:08:46 +0100 <[email protected]> wrote:
From: "Yann E. MORIN" <[email protected]>
Currently, the golang infrastructure forcibly sets the package
_DL_ENVvariable, instead of appending to it, which prevents packages from providing their own download environment variables.We fix that by using an append-assignment.
Note: when introduced, that variable was explicitly not documented, and is supposed to only be used by packages infrastructures. However, that variable exists, and it can be (ab)used by br2-external packages (most probably to ill effects, but heh!). We anyway leave it undocumented, like
_ROOTFS_PRE_CMD_HOOKS.
Quoted 4 lines
Signed-off-by Yann E. MORIN <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Christian Stewart <[email protected]>Cc Anisse Astier <[email protected]>
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 4/5 v2] package/pkg-golang: allow packages to define download environment
In reply to [email protected]Hi,
package/pkg-golang.mk
Quoted 25 lines · On Wed, Feb 9, 2022 at 8:09 AM <[email protected]> wrote:
From: "Yann E. MORIN" <[email protected]>
Currently, the golang infrastructure forcibly sets the package
_DL_ENVvariable, instead of appending to it, which prevents packages from providing their own download environment variables.We fix that by using an append-assignment.
Note: when introduced, that variable was explicitly not documented, and is supposed to only be used by packages infrastructures. However, that variable exists, and it can be (ab)used by br2-external packages (most probably to ill effects, but heh!). We anyway leave it undocumented, like
_ROOTFS_PRE_CMD_HOOKS.Signed-off-by Yann E. MORIN <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Christian Stewart <[email protected]>Cc Anisse Astier <[email protected]>--- package/pkg-golang.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)package/pkg-golang.mk +0
-0
Best,
Christian
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
PATCH v2 5/5 package/pkg-golang: host-go is also a build dependency
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
Currently, host-go is a download dependency, because we need go for the vendoring during the downlaod step.
However, when using a package in override-srcdir, there is no download step, so host-go is not pulled in as a dependency, which will break the build of a single package from scratch.
We fix that by adding host-go as a standard dependency too.
--- package/pkg-golang.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
package/pkg-golang.mk +3 -1
@@ -47,8 +47,10 @@ $(2)_BUILD_OPTS += \ -trimpath \ -p $(PARALLEL_JOBS) -# Target packages need the Go compiler on the host. +# Target packages need the Go compiler on the host at download time (for +# vendoring), and at build and install time. $(2)_DOWNLOAD_DEPENDENCIES += host-go +$(2)_DEPENDENCIES += host-go $(2)_BUILD_TARGETS ?= .
Signature · 20 lines
2.25.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 5/5 v2] package/pkg-golang: host-go is also a build dependency
Quoted 9 lines · On Wed, 9 Feb 2022 17:08:47 +0100 <[email protected]> wrote:
From: "Yann E. MORIN" <[email protected]>
Currently, host-go is a download dependency, because we need go for the vendoring during the downlaod step.
However, when using a package in override-srcdir, there is no download step, so host-go is not pulled in as a dependency, which will break the build of a single package from scratch.
Quoted 6 lines
We fix that by adding host-go as a standard dependency too.
Signed-off-by Yann E. MORIN <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Christian Stewart <[email protected]>Cc Anisse Astier <[email protected]>
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Re: [Buildroot] [PATCH 5/5 v2] package/pkg-golang: host-go is also a build dependency
In reply to [email protected]package/pkg-golang.mk
Quoted 22 lines · On Wed, Feb 9, 2022 at 8:09 AM <[email protected]> wrote:
From: "Yann E. MORIN" <[email protected]>
Currently, host-go is a download dependency, because we need go for the vendoring during the downlaod step.
However, when using a package in override-srcdir, there is no download step, so host-go is not pulled in as a dependency, which will break the build of a single package from scratch.
We fix that by adding host-go as a standard dependency too.
Signed-off-by Yann E. MORIN <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Christian Stewart <[email protected]>Cc Anisse Astier <[email protected]>--- package/pkg-golang.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)package/pkg-golang.mk +0
-0
Best,
Christian
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot