Skip to contentSkip to conversation

package/pkg-golang: simplify installing multiple binaries

PATCH Applied [email protected] 2 participants 19 messages Jul 1, 2025 – Sep 11, 2025

lore
Share & tools
lore

[email protected]

author
#0 lore raw

v2 cover package/pkg-golang: simplify installing multiple binaries

From: "Yann E. MORIN" <[email protected]>

Hello All!

This small series aims at simplifying the golang-package infra when a package builds multiple targets and thus installs multiple binaries.

Changes v1 -> v2:
- account for distribution-registry, package added since v1 was posted

Regards,
Yann E. MORIN.

The following changes since commit 901b9e19ed3741d0cc379ff8f145b2294a3bd09b

package/kvmtool: fix build failure w/ musl (2025-06-30 22:20:31 +0200)

are available as patches in this mail series,

for you to apply patches up to 71793243b832c0c9f397911ce0bdf08e03f660b4

package/pkg-golang: catch use of legacy FOO_INSTALL_BINS (2025-07-01 15:43:33 +0200)

----------------------------------------------------------------
Yann E. MORIN (4):
package/pkg-golang: simplify installing multiple binaries
package: drop default _INSTALL_BINS in golang-package package/cni-plugin: simplify installation package/pkg-golang: catch use of legacy FOO_INSTALL_BINS

 docs/manual/adding-packages-golang.adoc            | 26 +++++++++++-----------
 docs/manual/migrating.adoc                         |  5 +++++
 .../amazon-ecr-credential-helper.mk                |  1 -
 package/cni-plugins/cni-plugins.mk                 |  7 +++---
 package/containerd/containerd.mk                   |  1 -
 package/delve/delve.mk                             |  2 --
 .../distribution-registry/distribution-registry.mk |  1 -
 package/docker-cli/docker-cli.mk                   |  2 --
 package/docker-engine/docker-engine.mk             |  2 --
 package/mender-artifact/mender-artifact.mk         |  3 ---
 package/moby-buildkit/moby-buildkit.mk             |  4 ----
 package/pkg-golang.mk                              | 17 ++++++++++++--
 package/tailscale/tailscale.mk                     |  1 -
 13 files changed, 36 insertions(+), 36 deletions(-)

--

                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | 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

author
#1 lore raw

PATCH v2 1/4 package/pkg-golang: simplify installing multiple binaries

From: "Yann E. MORIN" <[email protected]>

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 <[email protected]>
Cc Christian Stewart <[email protected]>
---
 docs/manual/adding-packages-golang.adoc | 26 ++++++++++++-------------
 package/pkg-golang.mk                   | 11 +++++++++--
 2 files changed, 22 insertions(+), 15 deletions(-)
docs/manual/adding-packages-golang.adoc +13 -13
index 6de0916a83..21b6a122a9 100644
@@ -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
package/pkg-golang.mk +9 -2
index a4e8bd30cc..ff8d28aa7e 100644
@@ -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
Signature · 18 lines
2.34.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
Reviewed-by Romain Naour on v2 1/4
#2 lore raw

Hello Yann, All,

Le 01/07/2025 à 15:45, [email protected] a écrit :

Quoted 32 lines

From: "Yann E. MORIN" <[email protected]>

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.

Quoted 6 lines

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 <[email protected]>
Cc Christian Stewart <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Since it's about a package infrastucture change, I prefer wait for a second review.

Quoted 51 lines
---
 docs/manual/adding-packages-golang.adoc | 26 ++++++++++++-------------
 package/pkg-golang.mk                   | 11 +++++++++--
 2 files changed, 22 insertions(+), 15 deletions(-)
docs/manual/adding-packages-golang.adoc +13 -13
index 6de0916a83..21b6a122a9 100644
@@ -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
package/pkg-golang.mk +0 -0
index a4e8bd30cc..ff8d28aa7e 100644
@@ -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)

package/pkg-golang.mk $(2)_BUILD_TARGETS ?= . · line 73

Quoted 10 lines
package/pkg-golang.mk +9 -0
+$(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

Is our testsuite is testing each use case?

Best regards,
Romain

package/pkg-golang.mk $(2)_BUILD_TARGETS ?= . · line 76

Quoted 5 lines
package/pkg-golang.mk +0 -2
-
-$(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

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Reviewed-by Christian Stewart
#3 lore raw

Hi Yann, Romain, All,

Quoted 7 lines · Romain Naour
Quoted 6 lines · Le 01/07/2025 à 15:45, [email protected] a écrit :

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;
Quoted 7 lines
Quoted 7 lines

- 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.

This looks great to me. It's just improving the default cases. We can still override _INSTALL_BINS.

Quoted 7 lines
Quoted 7 lines

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.

Is there any case where we would still want to override this? I guess the logic is we would never bother building a binary if we don't install it. This makes sense to me but I don't think of any exceptions at the moment. I haven't touched this in so long so I don't know for sure.

I will go ahead and test this series on my end.

Reviewed-by Christian Stewart <[email protected]>

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

author
#4 lore raw

Christian, All,

On 2025-07-06 15:06 -0700, Christian Stewart spake thusly:

Quoted 2 lines · Romain Naour
Quoted 1 line · Le 01/07/2025 à 15:45, [email protected] a écrit :

[--SNIP--]

Quoted 4 lines
Quoted 3 lines
Quoted 3 lines

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.

Is there any case where we would still want to override this?

The thing is that, in the case of multiple _BUILD_TARGETS, theinfra generates executables based on the basename of each _BUILD_TARGETS; as the example in the doc describes; for example, given:
FOO_BUILD_TARGETS = cmd/docker cmd/dockerd

then the generated executables are "docker" and "dockerd".

So, if we allow setting _INSTALL_BINS to an arbitrary list, it can easily get out of sync with the list in _BUILD_TARGETS. And there is also no way to set the name of the generated executable for each entry in _BUILD_TARGETS...

So, it does not make sense to keep _INSTALL_BINS settable (see the last patch in the series).

Quoted 3 lines

I guess
the logic is we would never bother building a binary if we don't install it.

Exactly: if you don't want it installed, don't build it. ;-)

If the package has optional binaries, they can just be conditionally added to _BUILD_TARGETS just as we do it for any kind of package infra.

Quoted 3 lines

This makes sense to me but I don't think of any exceptions at the moment. I haven't touched this in so long so I don't know for sure.

Eh, I know the feeling. ;-)

Quoted 2 lines

I will go ahead and test this series on my end.

Reviewed-by Christian Stewart <[email protected]>

Thanks for the feedback! 👍

Regards,
Yann E. MORIN.

Signature · 23 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | 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
author
#5 lore raw
In reply to Romain Naour via buildroot

Romain, All,

On 2025-07-05 22:51 +0200, Romain Naour spake thusly:

Quoted 4 lines

Le 01/07/2025 à 15:45, [email protected] a écrit :

Quoted 3 lines

From: "Yann E. MORIN" <[email protected]>
Currently, when a golang package defines multiple _BUILD_TARGETS, it has to basically repeat the same list in its _INSTALL_BINS.

Nicolas BUFFON <[email protected]> >

Quoted 4 lines
Quoted 2 lines
Signed-off-by Yann E. MORIN <[email protected]>
Cc Christian Stewart <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Since it's about a package infrastucture change, I prefer wait for a second review.

Thanks for the review!

[--SNIP--]

Quoted 12 lines
Quoted 12 lines
package/pkg-golang.mk +4 -0
index a4e8bd30cc..ff8d28aa7e 100644
@@ -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)
Quoted 8 lines

package/pkg-golang.mk $(2)_BUILD_TARGETS ?= . · line 73

Quoted 6 lines
package/pkg-golang.mk +5 -0
+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

Is our testsuite is testing each use case?

Depends: do we have at least one package to cover each case? ;-)

I'll try to dig that in the coming days.

Thanks for the feedback. :-)

Regards,
Yann E. MORIN.

Signature · 23 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | 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
author
#6 lore raw
In reply to Romain Naour via buildroot

Romain, All,

On 2025-07-05 22:51 +0200, Romain Naour spake thusly:

Quoted 4 lines

Le 01/07/2025 à 15:45, [email protected] a écrit :

Quoted 3 lines

From: "Yann E. MORIN" <[email protected]>
Currently, when a golang package defines multiple _BUILD_TARGETS, it has to basically repeat the same list in its _INSTALL_BINS.

[--SNIP--]

Quoted 8 lines
Quoted 6 lines

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 <[email protected]>
Cc Christian Stewart <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Since it's about a package infrastucture change, I prefer wait for a second review.

What about the status of this series? Christian has provided his Reviewed-by a while back...

Regards,
Yann E. MORIN.

Signature · 22 lines
.-----------------.--------------------:̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅_̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅:------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | 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
#7 lore raw

Hi Yann,

Quoted 14 lines · On Tue, Sep 9, 2025, 12:47 AM <[email protected]> wrote:

Romain, All,

On 2025-07-05 22:51 +0200, Romain Naour spake thusly:

Quoted 3 lines · Le 01/07/2025 à 15:45, [email protected] a écrit :
Quoted 2 lines

From: "Yann E. MORIN" <[email protected]>
Currently, when a golang package defines multiple _BUILD_TARGETS, it

has

Quoted 1 line
Quoted 1 line

to basically repeat the same list in its _INSTALL_BINS.

[--SNIP--]

Quoted 1 line
Quoted 1 line

We now consider that _INSTALL_BINS is an internal implementation

details

Quoted 3 lines
Quoted 3 lines

that should no longer be exposed to the users, so we drop it from the documentation; we rephrase the corresponding part for _BUILD_TARGETS.

Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Signed-off-by Yann E. MORIN <[email protected]>
Cc Christian Stewart <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Since it's about a package infrastucture change, I prefer wait for a

second review.

What about the status of this series? Christian has provided his Reviewed-by a while back...

It still looks good to me!

Best regards,
Christian

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Applied
#8 lore raw

Hello Yann, Christian, All,

Le 09/09/2025 à 19:56, Christian Stewart a écrit :

Quoted 26 lines

Hi Yann,

On Tue, Sep 9, 2025, 12:47 AM <[email protected] <mailto:[email protected]>> wrote:

Romain, All,

On 2025-07-05 22:51 +0200, Romain Naour spake thusly:
> Le 01/07/2025 à 15:45, [email protected] <mailto:[email protected]> a écrit :
> > From: "Yann E. MORIN" <[email protected] <mailto:[email protected]>> > > Currently, when a golang package defines multiple _BUILD_TARGETS, it has > > to basically repeat the same list in its _INSTALL_BINS. [--SNIP--]
> > 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 <[email protected] <mailto:[email protected]>>
> > Cc: Christian Stewart <[email protected] <mailto:[email protected]>> > Reviewed-by: Romain Naour <[email protected] <mailto:[email protected]>>
> Since it's about a package infrastucture change, I prefer wait for a second review.

Quoted 5 lines

What about the status of this series? Christian has provided his Reviewed-by a while back...

It still looks good to me!

Thanks for the reminder!
Now the 2025.08 is release (and next merged in master), we can go ahead.

Btw, I replaced 2025.08 by 2025.11 in the last commit.

Applied to master, thanks.

Best regards,
Romain

Quoted 3 lines

Best regards,
Christian

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

author
#9 lore raw

Romain, All,

On 2025-09-10 13:19 +0200, Romain Naour spake thusly:

Quoted 9 lines

Le 09/09/2025 à 19:56, Christian Stewart a écrit :

Quoted 5 lines
Quoted 2 lines · On Tue, Sep 9, 2025, 12:47 AM <[email protected]…

What about the status of this series? Christian has provided his Reviewed-by a while back...

It still looks good to me!

Thanks for the reminder!
Now the 2025.08 is release (and next merged in master), we can go ahead. Btw, I replaced 2025.08 by 2025.11 in the last commit.

I might have been a little tiny weeny bit too optimistic. 😜

Quoted 1 line

Applied to master, thanks.

Thanks! 👍

Regards,
Yann E. MORIN.

Signature · 23 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | 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
#10 lore raw

Yann,

Quoted 7 lines · On Wed, Sep 10, 2025 at 4:41 AM <[email protected]> wrote:

Romain, All,

On 2025-09-10 13:19 +0200, Romain Naour spake thusly:

Quoted 3 lines · Christian Stewart
Quoted 2 lines

On Tue, Sep 9, 2025, 12:47 AM <[email protected] <mailto:[email protected]>> wrote:

Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines

What about the status of this series? Christian has provided his Reviewed-by a while back...

It still looks good to me!

Thanks for the reminder!
Now the 2025.08 is release (and next merged in master), we can go ahead. Btw, I replaced 2025.08 by 2025.11 in the last commit.

I might have been a little tiny weeny bit too optimistic. 😜

Quoted 1 line

Applied to master, thanks.

Now that this is merged, how do I rename a build binary before installing?

Here's an example:

https://github.com/skiffos/buildroot/blob/skiff/package/genuinetools-img/genuinetools-img.mk

Thanks,
Christian Stewart
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

#11 lore raw

hi Yann,

Quoted 20 lines · Christian Stewart

Yann,

Quoted 16 lines · On Wed, Sep 10, 2025 at 4:41 AM <[email protected]> wrote:

Romain, All,

On 2025-09-10 13:19 +0200, Romain Naour spake thusly:

Quoted 9 lines · Christian Stewart
Quoted 5 lines
Quoted 2 lines · On Tue, Sep 9, 2025, 12:47 AM <[email protected]…

What about the status of this series? Christian has provided his Reviewed-by a while back...

It still looks good to me!

Thanks for the reminder!
Now the 2025.08 is release (and next merged in master), we can go ahead. Btw, I replaced 2025.08 by 2025.11 in the last commit.

I might have been a little tiny weeny bit too optimistic. 😜

Quoted 7 lines
Quoted 1 line
Quoted 1 line

Applied to master, thanks.

Now that this is merged, how do I rename a build binary before installing?

Here's an example:

https://github.com/skiffos/buildroot/blob/skiff/package/genuinetools-img/genuinetools-img.mk

Oh, I guess we can still just set BIN_NAME. Ignore!

Thanks,
Christian
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

author
#12 lore raw

Christian, All,

On 2025-09-10 12:13 -0700, Christian Stewart spake thusly:

Quoted 2 lines

On Wed, Sep 10, 2025 at 12:07 PM Christian Stewart <[email protected]> wrote:

[--SNIP--]

Quoted 4 lines
Quoted 3 lines

Now that this is merged, how do I rename a build binary before installing? Here's an example:
https://github.com/skiffos/buildroot/blob/skiff/package/genuinetools-img/genuinetools-img.mk

Oh, I guess we can still just set BIN_NAME. Ignore!

1. Yes, you can still set FOO_BIN_NAME when there is a single binary to install; quoting the manual:

* FOO_BUILD_TARGETS is '.'. In this case, we assume only one binary 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 [...]. 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; [...]

2. Unless I'm mistaken, the binary your package installs is named after the package, so you should not even need to specify it, as this is the default (and already was prior to this series); i.e. there should be no need for (the same way you did not specify it for the target variant):
HOST_GENUINETOOLS_IMG_BIN_NAME = genuinetools-img

Regards,
Yann E. MORIN.

Signature · 23 lines
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | 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
author
#13 lore raw

PATCH v2 2/4 package: drop default _INSTALL_BINS in golang-package

In reply to [email protected]

From: "Yann E. MORIN" <[email protected]>

Now that the pkg-golang infra automatically sets _INSTALL_BINS by default to the list of notdir of _BUILD_TARGETS, there is no need to do that in packages anymore.

Most packages were already using the notdir construct, so those are trivially fixed; a few had a hard-coded list that matched the built targets list, so they too are trivially fixed.

host-mender-artifact was slightly different, in that it explicitly set the _BIN_NAME to mender-artifact, which happens to be the default; it also set _INSTALL_BINS to _BIN_NAME, so again using the default. This package can also be fixed easily.

Signed-off-by Yann E. MORIN <[email protected]>
Cc Angelo Compagnucci <[email protected]>
Cc Christian Stewart <[email protected]>
Cc James Hilliard <[email protected]>

---
Changes v1 -> v2:
- account for distribution-registry, new package added after v1 was posted

---
 .../amazon-ecr-credential-helper.mk                           | 1 -
 package/containerd/containerd.mk                              | 1 -
 package/delve/delve.mk                                        | 2 --
 package/distribution-registry/distribution-registry.mk        | 1 -
 package/docker-cli/docker-cli.mk                              | 2 --
 package/docker-engine/docker-engine.mk                        | 2 --
 package/mender-artifact/mender-artifact.mk                    | 3 ---
 package/moby-buildkit/moby-buildkit.mk                        | 4 ----
 package/tailscale/tailscale.mk                                | 1 -
 9 files changed, 17 deletions(-)
package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk +0 -1
index acfeea16fb..ad75ed3360 100644
@@ -15,6 +15,5 @@ AMAZON_ECR_CREDENTIAL_HELPER_SUBDIR = ecr-login
 
 AMAZON_ECR_CREDENTIAL_HELPER_GOMOD = ./cli
 AMAZON_ECR_CREDENTIAL_HELPER_BUILD_TARGETS = docker-credential-ecr-login
-AMAZON_ECR_CREDENTIAL_HELPER_INSTALL_BINS = docker-credential-ecr-login
 
 $(eval $(golang-package))
package/containerd/containerd.mk +0 -1
index 1f70a26ebf..2ef70ab5d7 100644
@@ -20,7 +20,6 @@ CONTAINERD_BUILD_TARGETS = \
 	cmd/containerd-shim-runc-v2 \
 	cmd/ctr
 
-CONTAINERD_INSTALL_BINS = $(notdir $(CONTAINERD_BUILD_TARGETS))
 CONTAINERD_TAGS = no_aufs
 
 ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
package/delve/delve.mk +0 -2
index 408286e3b4..8206721fe2 100644
@@ -12,11 +12,9 @@ DELVE_DEPENDENCIES = host-pkgconf
 
 DELVE_TAGS = cgo
 DELVE_BUILD_TARGETS = cmd/dlv
-DELVE_INSTALL_BINS = $(notdir $(DELVE_BUILD_TARGETS))
 
 HOST_DELVE_TAGS = cgo
 HOST_DELVE_BUILD_TARGETS = cmd/dlv
-HOST_DELVE_INSTALL_BINS = $(notdir $(HOST_DELVE_BUILD_TARGETS))
 
 $(eval $(golang-package))
 $(eval $(host-golang-package))
package/distribution-registry/distribution-registry.mk +0 -1
index 901b9c40e5..a01a3c1710 100644
@@ -18,7 +18,6 @@ DISTRIBUTION_REGISTRY_BUILD_TARGETS = cmd/registry
 # distribution-registry builds and installs the 'registry' executable, but
 # that name is a bit too generic. Rename it to match the package name.
 DISTRIBUTION_REGISTRY_BIN_NAME = distribution-registry
-DISTRIBUTION_REGISTRY_INSTALL_BINS = distribution-registry
 
 # Inject the version as if done by upstream's wrapper Makefile
 define DISTRIBUTION_REGISTRY_SET_VERSION
package/docker-cli/docker-cli.mk +0 -2
index e118481838..7386b007cd 100644
@@ -38,6 +38,4 @@ define DOCKER_CLI_FIX_VENDORING
 endef
 DOCKER_CLI_POST_EXTRACT_HOOKS += DOCKER_CLI_FIX_VENDORING
 
-DOCKER_CLI_INSTALL_BINS = $(notdir $(DOCKER_CLI_BUILD_TARGETS))
-
 $(eval $(golang-package))
package/docker-engine/docker-engine.mk +0 -2
index c39dc2b440..181975b26b 100644
@@ -70,8 +70,6 @@ define DOCKER_ENGINE_FIX_VENDORING
 endef
 DOCKER_ENGINE_POST_EXTRACT_HOOKS += DOCKER_ENGINE_FIX_VENDORING
 
-DOCKER_ENGINE_INSTALL_BINS = $(notdir $(DOCKER_ENGINE_BUILD_TARGETS))
-
 define DOCKER_ENGINE_INSTALL_INIT_SYSTEMD
 	$(INSTALL) -D -m 0644 $(@D)/contrib/init/systemd/docker.service \
 		$(TARGET_DIR)/usr/lib/systemd/system/docker.service
package/mender-artifact/mender-artifact.mk +0 -3
index bcab91890a..7d6f0929e2 100644
@@ -115,7 +115,4 @@ HOST_MENDER_ARTIFACT_GO_ENV += \
 
 HOST_MENDER_ARTIFACT_LDFLAGS = -X github.com/mendersoftware/mender-artifact/cli.Version=$(HOST_MENDER_ARTIFACT_VERSION)
 
-HOST_MENDER_ARTIFACT_BIN_NAME = mender-artifact
-HOST_MENDER_ARTIFACT_INSTALL_BINS = $(HOST_MENDER_ARTIFACT_BIN_NAME)
-
 $(eval $(host-golang-package))
package/moby-buildkit/moby-buildkit.mk +0 -4
index 91560c1ed1..4ae1abde3a 100644
@@ -17,12 +17,8 @@ MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
 MOBY_BUILDKIT_LDFLAGS = \
 	-X $(MOBY_BUILDKIT_GOMOD)/version.Version="$(MOBY_BUILDKIT_VERSION)"
 
-MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(MOBY_BUILDKIT_BUILD_TARGETS))
-
 HOST_MOBY_BUILDKIT_TAGS = cgo
 HOST_MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
 
-HOST_MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(HOST_MOBY_BUILDKIT_BUILD_TARGETS))
-
 $(eval $(golang-package))
 $(eval $(host-golang-package))
package/tailscale/tailscale.mk +0 -1
index 7019b9afc9..8f25b0cbd1 100644
@@ -10,7 +10,6 @@ TAILSCALE_LICENSE = BSD-3-Clause
 TAILSCALE_LICENSE_FILES = LICENSE
 TAILSCALE_GOMOD = tailscale.com
 TAILSCALE_BUILD_TARGETS = cmd/tailscale cmd/tailscaled
-TAILSCALE_INSTALL_BINS = tailscale tailscaled
 TAILSCALE_LDFLAGS = \
 	-X tailscale.com/version.longStamp=$(TAILSCALE_VERSION) \
 	-X tailscale.com/version.shortStamp=$(TAILSCALE_VERSION)
Signature · 18 lines
2.34.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
Reviewed-by Romain Naour on v2 2/4
#14 lore raw

Re: [Buildroot] [PATCH 2/4 v2] package: drop default _INSTALL_BINS in golang-package

Hello Yann, All,

Le 01/07/2025 à 15:45, [email protected] a écrit :

Quoted 15 lines

From: "Yann E. MORIN" <[email protected]>

Now that the pkg-golang infra automatically sets _INSTALL_BINS by default to the list of notdir of _BUILD_TARGETS, there is no need to do that in packages anymore.

Most packages were already using the notdir construct, so those are trivially fixed; a few had a hard-coded list that matched the built targets list, so they too are trivially fixed.

host-mender-artifact was slightly different, in that it explicitly set the _BIN_NAME to mender-artifact, which happens to be the default; it also set _INSTALL_BINS to _BIN_NAME, so again using the default. This package can also be fixed easily.

Quoted 4 lines
Signed-off-by Yann E. MORIN <[email protected]>
Cc Angelo Compagnucci <[email protected]>
Cc Christian Stewart <[email protected]>
Cc James Hilliard <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Best regards,
Romain

Quoted 126 lines

---
Changes v1 -> v2:
- account for distribution-registry, new package added after v1 was posted

---
 .../amazon-ecr-credential-helper.mk                           | 1 -
 package/containerd/containerd.mk                              | 1 -
 package/delve/delve.mk                                        | 2 --
 package/distribution-registry/distribution-registry.mk        | 1 -
 package/docker-cli/docker-cli.mk                              | 2 --
 package/docker-engine/docker-engine.mk                        | 2 --
 package/mender-artifact/mender-artifact.mk                    | 3 ---
 package/moby-buildkit/moby-buildkit.mk                        | 4 ----
 package/tailscale/tailscale.mk                                | 1 -
 9 files changed, 17 deletions(-)
package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk +0 -1
index acfeea16fb..ad75ed3360 100644
@@ -15,6 +15,5 @@ AMAZON_ECR_CREDENTIAL_HELPER_SUBDIR = ecr-login
 
 AMAZON_ECR_CREDENTIAL_HELPER_GOMOD = ./cli
 AMAZON_ECR_CREDENTIAL_HELPER_BUILD_TARGETS = docker-credential-ecr-login
-AMAZON_ECR_CREDENTIAL_HELPER_INSTALL_BINS = docker-credential-ecr-login
 
 $(eval $(golang-package))
package/containerd/containerd.mk +0 -1
index 1f70a26ebf..2ef70ab5d7 100644
@@ -20,7 +20,6 @@ CONTAINERD_BUILD_TARGETS = \
 	cmd/containerd-shim-runc-v2 \
 	cmd/ctr
 
-CONTAINERD_INSTALL_BINS = $(notdir $(CONTAINERD_BUILD_TARGETS))
 CONTAINERD_TAGS = no_aufs
 
 ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
package/delve/delve.mk +0 -2
index 408286e3b4..8206721fe2 100644
@@ -12,11 +12,9 @@ DELVE_DEPENDENCIES = host-pkgconf
 
 DELVE_TAGS = cgo
 DELVE_BUILD_TARGETS = cmd/dlv
-DELVE_INSTALL_BINS = $(notdir $(DELVE_BUILD_TARGETS))
 
 HOST_DELVE_TAGS = cgo
 HOST_DELVE_BUILD_TARGETS = cmd/dlv
-HOST_DELVE_INSTALL_BINS = $(notdir $(HOST_DELVE_BUILD_TARGETS))
 
 $(eval $(golang-package))
 $(eval $(host-golang-package))
package/distribution-registry/distribution-registry.mk +0 -1
index 901b9c40e5..a01a3c1710 100644
@@ -18,7 +18,6 @@ DISTRIBUTION_REGISTRY_BUILD_TARGETS = cmd/registry
 # distribution-registry builds and installs the 'registry' executable, but
 # that name is a bit too generic. Rename it to match the package name.
 DISTRIBUTION_REGISTRY_BIN_NAME = distribution-registry
-DISTRIBUTION_REGISTRY_INSTALL_BINS = distribution-registry
 
 # Inject the version as if done by upstream's wrapper Makefile
 define DISTRIBUTION_REGISTRY_SET_VERSION
package/docker-cli/docker-cli.mk +0 -2
index e118481838..7386b007cd 100644
@@ -38,6 +38,4 @@ define DOCKER_CLI_FIX_VENDORING
 endef
 DOCKER_CLI_POST_EXTRACT_HOOKS += DOCKER_CLI_FIX_VENDORING
 
-DOCKER_CLI_INSTALL_BINS = $(notdir $(DOCKER_CLI_BUILD_TARGETS))
-
 $(eval $(golang-package))
package/docker-engine/docker-engine.mk +0 -2
index c39dc2b440..181975b26b 100644
@@ -70,8 +70,6 @@ define DOCKER_ENGINE_FIX_VENDORING
 endef
 DOCKER_ENGINE_POST_EXTRACT_HOOKS += DOCKER_ENGINE_FIX_VENDORING
 
-DOCKER_ENGINE_INSTALL_BINS = $(notdir $(DOCKER_ENGINE_BUILD_TARGETS))
-
 define DOCKER_ENGINE_INSTALL_INIT_SYSTEMD
 	$(INSTALL) -D -m 0644 $(@D)/contrib/init/systemd/docker.service \
 		$(TARGET_DIR)/usr/lib/systemd/system/docker.service
package/mender-artifact/mender-artifact.mk +0 -3
index bcab91890a..7d6f0929e2 100644
@@ -115,7 +115,4 @@ HOST_MENDER_ARTIFACT_GO_ENV += \
 
 HOST_MENDER_ARTIFACT_LDFLAGS = -X github.com/mendersoftware/mender-artifact/cli.Version=$(HOST_MENDER_ARTIFACT_VERSION)
 
-HOST_MENDER_ARTIFACT_BIN_NAME = mender-artifact
-HOST_MENDER_ARTIFACT_INSTALL_BINS = $(HOST_MENDER_ARTIFACT_BIN_NAME)
-
 $(eval $(host-golang-package))
package/moby-buildkit/moby-buildkit.mk +0 -4
index 91560c1ed1..4ae1abde3a 100644
@@ -17,12 +17,8 @@ MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
 MOBY_BUILDKIT_LDFLAGS = \
 	-X $(MOBY_BUILDKIT_GOMOD)/version.Version="$(MOBY_BUILDKIT_VERSION)"
 
-MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(MOBY_BUILDKIT_BUILD_TARGETS))
-
 HOST_MOBY_BUILDKIT_TAGS = cgo
 HOST_MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
 
-HOST_MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(HOST_MOBY_BUILDKIT_BUILD_TARGETS))
-
 $(eval $(golang-package))
 $(eval $(host-golang-package))
package/tailscale/tailscale.mk +0 -0
index 7019b9afc9..8f25b0cbd1 100644

package/tailscale/tailscale.mk TAILSCALE_LICENSE = BSD-3-Clause · line 15

Quoted 7 lines
package/tailscale/tailscale.mk +0 -1
@@ -10,7 +10,6 @@ TAILSCALE_LICENSE = BSD-3-Clause
 TAILSCALE_LICENSE_FILES = LICENSE
 TAILSCALE_GOMOD = tailscale.com
 TAILSCALE_BUILD_TARGETS = cmd/tailscale cmd/tailscaled
-TAILSCALE_INSTALL_BINS = tailscale tailscaled
 TAILSCALE_LDFLAGS = \
 	-X tailscale.com/version.longStamp=$(TAILSCALE_VERSION) \
 	-X tailscale.com/version.shortStamp=$(TAILSCALE_VERSION)

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

author
#15 lore raw

PATCH v2 3/4 package/cni-plugin: simplify installation

In reply to [email protected]

From: "Yann E. MORIN" <[email protected]>

In all theory, we could iterate over CNI_PLUGINS_INSTALL_BINS, which already contains the basenames $(notdir) of the binaries to install, but *_INSTALL_BINS is now an internal implementation detail, and can't be guaranteed to be stable.

Hence, iterate over the list of targets, and somewhat duplicate the install commands from the infra, using make's $(notdir) rather than calling to the shell's to call basename.

Note: we need to stop setting _INSTALL_BINS, as a following commit will check that it is not explicitly set, and fail otherwise.

Signed-off-by Yann E. MORIN <[email protected]>
Cc Christian Stewart <[email protected]>
---
 package/cni-plugins/cni-plugins.mk | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
package/cni-plugins/cni-plugins.mk +3 -4
index bccc1674aa..9a9ecf103b 100644
@@ -27,7 +27,6 @@ CNI_PLUGINS_BUILD_TARGETS = \
 	plugins/meta/portmap \
 	plugins/meta/tuning \
 	plugins/meta/vrf
-CNI_PLUGINS_INSTALL_BINS = $(CNI_PLUGINS_BUILD_TARGETS)
 
 ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
 CNI_PLUGINS_DEPENDENCIES += libapparmor

@@ -46,9 +45,9 @@ endif
 
 define CNI_PLUGINS_INSTALL_TARGET_CMDS
 	$(INSTALL) -d -m 0755 $(TARGET_DIR)/opt/cni/bin
-	$(foreach d,$(CNI_PLUGINS_INSTALL_BINS),\
-		$(INSTALL) -D -m 0755 $(@D)/bin/$$(basename $(d)) \
-			$(TARGET_DIR)/opt/cni/bin
+	$(foreach d,$(CNI_PLUGINS_BUILD_TARGETS),\
+		$(INSTALL) -D -m 0755 $(@D)/bin/$(notdir $(d)) \
+			$(TARGET_DIR)/opt/cni/bin/$(notdir $(d))
 	)
 endef
Signature · 18 lines
2.34.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
Reviewed-by Romain Naour on v2 3/4
#16 lore raw

Re: [Buildroot] [PATCH 3/4 v2] package/cni-plugin: simplify installation

Hello Yann, All,

Le 01/07/2025 à 15:45, [email protected] a écrit :

Quoted 11 lines

From: "Yann E. MORIN" <[email protected]>

In all theory, we could iterate over CNI_PLUGINS_INSTALL_BINS, which already contains the basenames $(notdir) of the binaries to install, but *_INSTALL_BINS is now an internal implementation detail, and can't be guaranteed to be stable.

Hence, iterate over the list of targets, and somewhat duplicate the install commands from the infra, using make's $(notdir) rather than calling to the shell's to call basename.

Quoted 5 lines

Note: we need to stop setting _INSTALL_BINS, as a following commit will check that it is not explicitly set, and fail otherwise.

Signed-off-by Yann E. MORIN <[email protected]>
Cc Christian Stewart <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Best regards,
Romain

Quoted 19 lines
---
 package/cni-plugins/cni-plugins.mk | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
package/cni-plugins/cni-plugins.mk +0 -1
index bccc1674aa..9a9ecf103b 100644
@@ -27,7 +27,6 @@ CNI_PLUGINS_BUILD_TARGETS = \
 	plugins/meta/portmap \
 	plugins/meta/tuning \
 	plugins/meta/vrf
-CNI_PLUGINS_INSTALL_BINS = $(CNI_PLUGINS_BUILD_TARGETS)
 
 ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
 CNI_PLUGINS_DEPENDENCIES += libapparmor

@@ -46,9 +45,9 @@ endif
 
 define CNI_PLUGINS_INSTALL_TARGET_CMDS

package/cni-plugins/cni-plugins.mk endif · line 53

Quoted 10 lines
package/cni-plugins/cni-plugins.mk +3 -3
 	$(INSTALL) -d -m 0755 $(TARGET_DIR)/opt/cni/bin
-	$(foreach d,$(CNI_PLUGINS_INSTALL_BINS),\
-		$(INSTALL) -D -m 0755 $(@D)/bin/$$(basename $(d)) \
-			$(TARGET_DIR)/opt/cni/bin
+	$(foreach d,$(CNI_PLUGINS_BUILD_TARGETS),\
+		$(INSTALL) -D -m 0755 $(@D)/bin/$(notdir $(d)) \
+			$(TARGET_DIR)/opt/cni/bin/$(notdir $(d))
 	)
 endef

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

author
#17 lore raw

PATCH v2 4/4 package/pkg-golang: catch use of legacy FOO_INSTALL_BINS

In reply to [email protected]

From: "Yann E. MORIN" <[email protected]>

Signed-off-by Yann E. MORIN <[email protected]>
Cc Christian Stewart <[email protected]>
---
 docs/manual/migrating.adoc | 5 +++++
 package/pkg-golang.mk      | 6 ++++++
 2 files changed, 11 insertions(+)
docs/manual/migrating.adoc +5 -0
index 4e6225a987..6ecc992502 100644
@@ -222,3 +222,8 @@ from +-cargo2+ to +-cargo4+.
 In 2025.08, starting with systemd version 257, systemd-networkd requires kernel
 5.4 or later. If you are still using a kernel older than 5.4, please update
 your kernel or use an alternative network manager.
+
+[[migrating-golang-packages]]
+In 2025.08, the +FOO_INSTALL_BINS+ variable for golang packages is no longer
+supported; the list of binaries to install is automatically derived from
+the +FOO_BULD_TARGETS+ variable.
package/pkg-golang.mk +6 -0
index ff8d28aa7e..ffd50adecc 100644
@@ -40,6 +40,12 @@ GO_BIN = $(HOST_DIR)/bin/go
 
 define inner-golang-package
 
+# Legacy
+ifneq ($$($(2)_INSTALL_BINS),)
+$$(error Package $(1) sets $(2)_INSTALL_BINS, which is no longer supported; \
+see the manual: https://buildroot.org/manual.html#migrating-golang-package )
+endif
+
 $(2)_BUILD_OPTS += \
 	-ldflags "$$($(2)_LDFLAGS)" \
 	-modcacherw \
Signature · 18 lines
2.34.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
Reviewed-by Romain Naour on v2 4/4
#18 lore raw

Re: [Buildroot] [PATCH 4/4 v2] package/pkg-golang: catch use of legacy FOO_INSTALL_BINS

Hello Yann, All,

Le 01/07/2025 à 15:45, [email protected] a écrit :

Quoted 4 lines

From: "Yann E. MORIN" <[email protected]>

Signed-off-by Yann E. MORIN <[email protected]>
Cc Christian Stewart <[email protected]>
Reviewed-by Romain Naour <[email protected]>

Best regards,
Romain

Quoted 25 lines
---
 docs/manual/migrating.adoc | 5 +++++
 package/pkg-golang.mk      | 6 ++++++
 2 files changed, 11 insertions(+)
docs/manual/migrating.adoc +5 -0
index 4e6225a987..6ecc992502 100644
@@ -222,3 +222,8 @@ from +-cargo2+ to +-cargo4+.
 In 2025.08, starting with systemd version 257, systemd-networkd requires kernel
 5.4 or later. If you are still using a kernel older than 5.4, please update
 your kernel or use an alternative network manager.
+
+[[migrating-golang-packages]]
+In 2025.08, the +FOO_INSTALL_BINS+ variable for golang packages is no longer
+supported; the list of binaries to install is automatically derived from
+the +FOO_BULD_TARGETS+ variable.
package/pkg-golang.mk +0 -0
index ff8d28aa7e..ffd50adecc 100644
@@ -40,6 +40,12 @@ GO_BIN = $(HOST_DIR)/bin/go
 
 define inner-golang-package

package/pkg-golang.mk GO_BIN = $(HOST_DIR)/bin/go · line 51

Quoted 10 lines
package/pkg-golang.mk +6 -0
 
+# Legacy
+ifneq ($$($(2)_INSTALL_BINS),)
+$$(error Package $(1) sets $(2)_INSTALL_BINS, which is no longer supported; \
+see the manual: https://buildroot.org/manual.html#migrating-golang-package )
+endif
+
 $(2)_BUILD_OPTS += \
 	-ldflags "$$($(2)_LDFLAGS)" \
 	-modcacherw \

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot