[Buildroot] [PATCH 1/4] package/goc: new virtual package

[Buildroot] [PATCH 1/4] package/goc: new virtual package

[Thomas Perale via buildroot]

This virtual package implement the already existing go compiler compiled
from source and shows it on the host package menu.

The usage of a virtual package on top of the go compiler enable the
supports of for multiple providers for the Go compiler.
Similarly to the rust compiler, a pre-built go compiler package will be
available in parallel to the current compiled go compiler package.

Signed-off-by: Thomas Perale <thomas.perale@mind.be>
---
 package/Config.in.host     |  1 +
 package/go/go.mk           |  2 ++
 package/goc/Config.in.host | 15 +++++++++++++++
 package/goc/goc.mk         |  7 +++++++
 4 files changed, 25 insertions(+)
 create mode 100644 package/goc/Config.in.host
 create mode 100644 package/goc/goc.mk

diff --git a/package/Config.in.host b/package/Config.in.host
index f437ef680c..8c44ff0cb4 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -38,6 +38,7 @@ menu "Host utilities"
 	source "package/gnupg/Config.in.host"
 	source "package/go/Config.in.host"
 	source "package/go-bootstrap/Config.in.host"
+	source "package/goc/Config.in.host"
 	source "package/google-breakpad/Config.in.host"
 	source "package/gptfdisk/Config.in.host"
 	source "package/imagemagick/Config.in.host"
diff --git a/package/go/go.mk b/package/go/go.mk
index 9f0fbbde00..96c756cb11 100644
--- a/package/go/go.mk
+++ b/package/go/go.mk
@@ -12,6 +12,8 @@ GO_LICENSE = BSD-3-Clause
 GO_LICENSE_FILES = LICENSE
 GO_CPE_ID_VENDOR = golang
 
+HOST_GO_PROVIDES = host-goc
+
 HOST_GO_DEPENDENCIES = host-go-bootstrap
 HOST_GO_GOPATH = $(HOST_DIR)/share/go-path
 HOST_GO_HOST_CACHE = $(HOST_DIR)/share/host-go-cache
diff --git a/package/goc/Config.in.host b/package/goc/Config.in.host
new file mode 100644
index 0000000000..b0266b50ea
--- /dev/null
+++ b/package/goc/Config.in.host
@@ -0,0 +1,15 @@
+config BR2_PACKAGE_HOST_GOC
+	bool "host go compiler"
+	depends on BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS
+	help
+	  Compiler for the Go language
+
+	  https://go.dev
+
+if BR2_PACKAGE_HOST_GOC
+
+config BR2_PACKAGE_PROVIDES_HOST_GOC
+	string
+	default "host-go"
+
+endif
diff --git a/package/goc/goc.mk b/package/goc/goc.mk
new file mode 100644
index 0000000000..3259618989
--- /dev/null
+++ b/package/goc/goc.mk
@@ -0,0 +1,7 @@
+################################################################################
+#
+# goc
+#
+################################################################################
+
+$(eval $(host-virtual-package))
-- 
2.37.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/go-bin: new package

[Christian Stewart via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 456 bytes --]

Hi all,

This looks interesting, one request though...

On Mon, Oct 17, 2022, 7:29 AM Thomas Perale <thomas.perale@essensium.com>
wrote:
> +       # Default to host-go-bin

> +       default "host-go-bin" if BR2_PACKAGE_HOST_GO_BIN
> +       default "host-go" if BR2_PACKAGE_HOST_GO


Please don't default to downloading something predompiled. Especially when
the behavior currently defaults to compiling everything from source.

Thanks,
Christian Stewart

[-- Attachment #1.2: Type: text/html, Size: 978 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Christian Stewart via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 564 bytes --]

Hi Thomas,

On Mon, Oct 17, 2022, 7:29 AM Thomas Perale <thomas.perale@essensium.com>
wrote:

> This virtual package implement the already existing go compiler compiled
> from source and shows it on the host package menu.
>
> The usage of a virtual package on top of the go compiler enable the
> supports of for multiple providers for the Go compiler.


Is it not possible to continue using the existing host-go target and simply
add a parameter which enables downloading the precompiled version instead?

Rather than add a new package.

Thanks,
Christian Stewart

[-- Attachment #1.2: Type: text/html, Size: 1047 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Yann E. MORIN]

Christian, All,

On 2022-10-17 09:06 -0700, Christian Stewart spake thusly:
> On Mon, Oct 17, 2022, 7:29 AM Thomas Perale < [1]thomas.perale@essensium.com> wrote:
>   This virtual package implement the already existing go compiler compiled
>   from source and shows it on the host package menu.
>   The usage of a virtual package on top of the go compiler enable the
>   supports of for multiple providers for the Go compiler.
> Is it not possible to continue using the existing host-go target and
> simply add a parameter which enables downloading the precompiled
> version instead?
> Rather than add a new package.

In fact, we want to have a similar implementation for rust, go, nodejs,
so (without looking at the details of this series), I guess Thomas
Perale took the same approach as the existing rust situation, like
Thomas Petazzoni did in the recent host-nodejs series:

    https://patchwork.ozlabs.org/project/buildroot/list/?series=319967

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/go-bin: new package

[Yann E. MORIN]

Christian, All,

On 2022-10-17 09:05 -0700, Christian Stewart via buildroot spake thusly:
> Hi all,
> This looks interesting, one request though...
> 
> On Mon, Oct 17, 2022, 7:29 AM Thomas Perale < [1]thomas.perale@essensium.com> wrote:
> > +       # Default to host-go-bin
> 
>   +       default "host-go-bin" if BR2_PACKAGE_HOST_GO_BIN
>   +       default "host-go" if BR2_PACKAGE_HOST_GO
> 
> Please don't default to downloading something predompiled. Especially when the behavior currently defaults to compiling everything
> from source.

Agreed. The default should be to build everything from source when
sources are available. The pre-built packages are only a fallback as
a convenience for those that are too much in a hurry.

Regards,
Yann E. MORIN.

> Thanks,
> Christian Stewart
> 
> Links:
> 1. mailto:thomas.perale@essensium.com

> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot


-- 
.-----------------.--------------------.------------------.--------------------.
|  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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Christian Stewart via buildroot]

Yann,

On Mon, Oct 17, 2022 at 10:55 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Christian, All,
>
> On 2022-10-17 09:06 -0700, Christian Stewart spake thusly:
> > On Mon, Oct 17, 2022, 7:29 AM Thomas Perale < [1]thomas.perale@essensium.com> wrote:
> >   This virtual package implement the already existing go compiler compiled
> >   from source and shows it on the host package menu.
> >   The usage of a virtual package on top of the go compiler enable the
> >   supports of for multiple providers for the Go compiler.
> > Is it not possible to continue using the existing host-go target and
> > simply add a parameter which enables downloading the precompiled
> > version instead?
> > Rather than add a new package.
>
> In fact, we want to have a similar implementation for rust, go, nodejs,
> so (without looking at the details of this series), I guess Thomas
> Perale took the same approach as the existing rust situation, like
> Thomas Petazzoni did in the recent host-nodejs series:
>
>     https://patchwork.ozlabs.org/project/buildroot/list/?series=319967

Thomas changed host-nodejs to be a metapackage:

https://patchwork.ozlabs.org/project/buildroot/patch/20220925204030.1661583-3-thomas.petazzoni@bootlin.com/

This is not what this series does, which is to add a new host-goc
package and refactor all Go packages to point to this new one.

Sidenote: having a rust-bin and nodejs-bin makes sense, as those take
a /very long/ time to compile. Having a go-bin on the other hand does
not make as much sense, because compiling the Go compiler is fast
(about 1 minute vs. Rust's 1 hour).

In my opinion:

 - Do not add a new host-goc package.
 - Add parameter to host-go to select which compiler to use:
   - bin
   - src
   - host go compiler (see patch linked below)
 - If src is buildable: default to it
 - If src is not buildable: default to host Go compiler
 - Or if the parameter is set: use bin download

This patch already solves the issue of selecting when to use the host
go compiler or not:

https://patchwork.ozlabs.org/project/buildroot/patch/20220725011322.1301684-1-christian@paral.in/

... it would be straightforward to add the Config parameter + binary
download to host-go after applying that commit.

My reasoning for why:

 - Avoid refactoring all Go packages across the tree.
 - Avoid confusing "goc" name (not used in Go ecosystem)
 - Backwards compatible with existing configs.
 - Fewer packages to maintain, easier to understand structure.

I'll have a look at submitting a RFC series adjusting this one to the
above structure.

Thanks,
Christian Stewart
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Thomas Perale via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 3555 bytes --]

Dear Christian, Yann,

Thank you for responses.

As Yann said my idea behing "goc" was to keep the structure the same as
the already existing case of 'rustc'. But I do agree with you Christian
the 'goc' name is confusing and don't make much sense. Right now I'm
already working on a second patch that will put every "go" related
packages in a sub-directory:

> package/
> ├─ go/
> │  ├─ go/
> │  ├─ go-bin/
> │  ├─ go-bootstrap/
> │  ├─ go.mk
> │  ├─ Config.in

This will remove the dependency to 'goc' virtual package because I will
move it to 'package/go/go.mk' with the common variable between every
'go*' package. I just want to keep the same structure as Rust from now
and if I do the modification of moving it to a subdir I also want to do
the modification for rust packages.

PERALE Thomas

On 10/17/22 20:10, Christian Stewart wrote:
> Yann,
>
> On Mon, Oct 17, 2022 at 10:55 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> Christian, All,
>>
>> On 2022-10-17 09:06 -0700, Christian Stewart spake thusly:
>>> On Mon, Oct 17, 2022, 7:29 AM Thomas Perale < [1]thomas.perale@essensium.com> wrote:
>>>   This virtual package implement the already existing go compiler compiled
>>>   from source and shows it on the host package menu.
>>>   The usage of a virtual package on top of the go compiler enable the
>>>   supports of for multiple providers for the Go compiler.
>>> Is it not possible to continue using the existing host-go target and
>>> simply add a parameter which enables downloading the precompiled
>>> version instead?
>>> Rather than add a new package.
>> In fact, we want to have a similar implementation for rust, go, nodejs,
>> so (without looking at the details of this series), I guess Thomas
>> Perale took the same approach as the existing rust situation, like
>> Thomas Petazzoni did in the recent host-nodejs series:
>>
>>     https://patchwork.ozlabs.org/project/buildroot/list/?series=319967
> Thomas changed host-nodejs to be a metapackage:
>
> https://patchwork.ozlabs.org/project/buildroot/patch/20220925204030.1661583-3-thomas.petazzoni@bootlin.com/
>
> This is not what this series does, which is to add a new host-goc
> package and refactor all Go packages to point to this new one.
>
> Sidenote: having a rust-bin and nodejs-bin makes sense, as those take
> a /very long/ time to compile. Having a go-bin on the other hand does
> not make as much sense, because compiling the Go compiler is fast
> (about 1 minute vs. Rust's 1 hour).
>
> In my opinion:
>
>  - Do not add a new host-goc package.
>  - Add parameter to host-go to select which compiler to use:
>    - bin
>    - src
>    - host go compiler (see patch linked below)
>  - If src is buildable: default to it
>  - If src is not buildable: default to host Go compiler
>  - Or if the parameter is set: use bin download
>
> This patch already solves the issue of selecting when to use the host
> go compiler or not:
>
> https://patchwork.ozlabs.org/project/buildroot/patch/20220725011322.1301684-1-christian@paral.in/
>
> ... it would be straightforward to add the Config parameter + binary
> download to host-go after applying that commit.
>
> My reasoning for why:
>
>  - Avoid refactoring all Go packages across the tree.
>  - Avoid confusing "goc" name (not used in Go ecosystem)
>  - Backwards compatible with existing configs.
>  - Fewer packages to maintain, easier to understand structure.
>
> I'll have a look at submitting a RFC series adjusting this one to the
> above structure.
>
> Thanks,
> Christian Stewart

[-- Attachment #1.2: Type: text/html, Size: 4901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/go-bin: new package

[Thomas Petazzoni via buildroot]

On Mon, 17 Oct 2022 20:03:50 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Agreed. The default should be to build everything from source when
> sources are available. The pre-built packages are only a fallback as
> a convenience for those that are too much in a hurry.

Except we do exactly the opposite for Rust, and I'm not sure for the
host compiler of those languages it is a good idea to cause such a
major impact on the default build time faced by our users. I clearly
understand the need to be able from source and appreciate how important
it is, but I'm not so sure the default should be to build all those
compilers from source.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Yann E. MORIN]

Christian, All,

On 2022-10-17 11:10 -0700, Christian Stewart spake thusly:
> On Mon, Oct 17, 2022 at 10:55 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2022-10-17 09:06 -0700, Christian Stewart spake thusly:
> > > On Mon, Oct 17, 2022, 7:29 AM Thomas Perale < [1]thomas.perale@essensium.com> wrote:
> > >   This virtual package implement the already existing go compiler compiled
> > >   from source and shows it on the host package menu.
> > >   The usage of a virtual package on top of the go compiler enable the
> > >   supports of for multiple providers for the Go compiler.
> > > Is it not possible to continue using the existing host-go target and
> > > simply add a parameter which enables downloading the precompiled
> > > version instead?
> > > Rather than add a new package.
> > In fact, we want to have a similar implementation for rust, go, nodejs,
> > so (without looking at the details of this series), I guess Thomas
> > Perale took the same approach as the existing rust situation, like
> > Thomas Petazzoni did in the recent host-nodejs series:
> >
> >     https://patchwork.ozlabs.org/project/buildroot/list/?series=319967
> 
> Thomas changed host-nodejs to be a metapackage:
> 
> https://patchwork.ozlabs.org/project/buildroot/patch/20220925204030.1661583-3-thomas.petazzoni@bootlin.com/

That patch does:
  - move the current host-nodejs package to host-nodejs-src as a
    host-generic-pacakge,
  - changes the existing host-nodejs from a host-generic-package to a
    host-virtual-package

(there is no such notion as a meta-package in Buildroot)

> This is not what this series does, which is to add a new host-goc
> package and refactor all Go packages to point to this new one.

I had a quick look, and it is indeed not what I expected it to be.

> Sidenote: having a rust-bin and nodejs-bin makes sense, as those take
> a /very long/ time to compile. Having a go-bin on the other hand does
> not make as much sense, because compiling the Go compiler is fast
> (about 1 minute vs. Rust's 1 hour).

It takes a bit longer here, as host-go-bootstrap depends on the
toolchain. So, running "make foo-legal-info" to check a go package,
does take ages.

> In my opinion:
>  - Do not add a new host-goc package.
>  - Add parameter to host-go to select which compiler to use:
>    - bin
>    - src

I am not sure I follow what you are saying. If you are sayng that it
should be as rust currently is, and as the nodejs proposal is, then
I agree. ;-)

>    - host go compiler (see patch linked below)

If we have a pre-built host-go in the tree, thetre is then no reason to
be able to use the host system go compiler, is there?

>  - If src is buildable: default to it
>  - If src is not buildable: default to host Go compiler
>  - Or if the parameter is set: use bin download
> 
> This patch already solves the issue of selecting when to use the host
> go compiler or not:
> 
> https://patchwork.ozlabs.org/project/buildroot/patch/20220725011322.1301684-1-christian@paral.in/
> 
> ... it would be straightforward to add the Config parameter + binary
> download to host-go after applying that commit.
> 
> My reasoning for why:
> 
>  - Avoid refactoring all Go packages across the tree.

Agreed. This should be transparent to packages.

>  - Avoid confusing "goc" name (not used in Go ecosystem)

Agreed.

>  - Backwards compatible with existing configs.

If that is possible, then agreed; if it is not, then use sensible
defaults (like build from source by default).

>  - Fewer packages to maintain,

Not too much of a headache...

>   easier to understand structure.

I am afraid I have to agree on that part, as the existing host-rust
strucutre bit me not too long ago...

> I'll have a look at submitting a RFC series adjusting this one to the
> above structure.

I would emphasize that we do want to have an similar implementation for
go that we have for rust, and as was proposed for node.

Regards,
Yann E. MORIN.

> Thanks,
> Christian Stewart

-- 
.-----------------.--------------------.------------------.--------------------.
|  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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Thomas Petazzoni via buildroot]

On Mon, 17 Oct 2022 19:55:00 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> In fact, we want to have a similar implementation for rust, go, nodejs,
> so (without looking at the details of this series), I guess Thomas
> Perale took the same approach as the existing rust situation, like
> Thomas Petazzoni did in the recent host-nodejs series:
> 
>     https://patchwork.ozlabs.org/project/buildroot/list/?series=319967

Yes and no, because Thomas Perale changed all packages using Go to use
host-goc instead of host-go, while my series keeps host-nodejs but
changes it from host-generic-package to host-virtual-package.

Also, I'd like to recap the naming we have:

 - Rust (existing)
   virtual package: 		host-rustc
   pre-compiled package:   	host-rust-bin
   from source package:         host-rust

 - NodeJS (proposed by me)
   virtual package:             host-nodejs
   pre-compiled package:        host-nodejs-bin
   from source package:         host-nodejs-src

   The odd thing here being that host-nodejs is a virtual package, but
   nodejs is a regular package building NodeJS from source for the
   target.

 - Go (proposed by Thomas Perale)
   virtual package:		host-goc
   pre-compiled package:        host-go-bin
   from source package:         host-go

So Thomas aligned on the naming used in the Rust world. I must say I do
have a preference for the naming I have chosen for NodeJS, which IMO is
clearer.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Christian Stewart via buildroot]

Hi Yann,

Just to reply to that one question on why a host go compiler is useful-

On Mon, Oct 17, 2022 at 11:45 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >    - host go compiler (see patch linked below)
>
> If we have a pre-built host-go in the tree, thetre is then no reason to
> be able to use the host system go compiler, is there?

The host Go compiler may be compiled from source (i.e. Gentoo) and the
user (me) wants to trust the gentoo binary for Go over downloading
another precompiled bin from the internet.

Thomas -

On Mon, Oct 17, 2022 at 11:48 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>  - NodeJS (proposed by me)
>    virtual package:             host-nodejs
>    pre-compiled package:        host-nodejs-bin
>    from source package:         host-nodejs-src
>
>    The odd thing here being that host-nodejs is a virtual package, but
>    nodejs is a regular package building NodeJS from source for the
>    target.
>
>  - Go (proposed by Thomas Perale)
>    virtual package:             host-goc
>    pre-compiled package:        host-go-bin
>    from source package:         host-go
>
> So Thomas aligned on the naming used in the Rust world. I must say I do
> have a preference for the naming I have chosen for NodeJS, which IMO is
> clearer.

I agree that the following would be preferable:

virtual package:             host-go
pre-compiled package:        host-go-bin
from source package:         host-go-src

... although I would submit that all 3 could live in a single host-go package.

Best,
Christian Stewart
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4] package/go-bin: new package

[Christian Stewart via buildroot]

Thomas,

On Mon, Oct 17, 2022 at 11:42 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Mon, 17 Oct 2022 20:03:50 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
>
> > Agreed. The default should be to build everything from source when
> > sources are available. The pre-built packages are only a fallback as
> > a convenience for those that are too much in a hurry.
>
> Except we do exactly the opposite for Rust, and I'm not sure for the
> host compiler of those languages it is a good idea to cause such a
> major impact on the default build time faced by our users. I clearly
> understand the need to be able from source and appreciate how important
> it is, but I'm not so sure the default should be to build all those
> compilers from source.

As you mentioned in a reply on the other email thread-

The main thing that takes time with host-go from source is building
the C toolchain.

Provided that the C toolchain is pre-compiled, building host-go
doesn't take long (~1-2 mins).

Best regards,
Christian Stewart
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4] package/goc: new virtual package

[Thomas Perale via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 3099 bytes --]

Dear Christian, Thomas,

I also do agree renaming the 'go' package to 'go-src' is clearer. But then
to not modify the content of `package/pkg-golang.mk` I will also need to
move the variable used by `package/pkg-golang.mk` aswell as `package/go-src/
go-src.mk` to `package/go/go.mk` (for instance `HOST_GO_COMMON_ENV`,
`HOST_GO_TARGET_ENV`, ...) or they will be renamed to `HOST_GO_SRC_*`.
Correct me if I'm wrong but there is no way to predict the order of
inclusion of '.mk' files, so `package/go-src/go-src.mk` might access to
undefined variable.

This is why I think a next patch should propose the same structure for
`nodejs`, `rust`, `go` using subdirectories:

package/
├─ go/
│  ├─ go-src/
│  ├─ go-bin/
│  ├─ go-bootstrap/
│  ├─ go.mk (<---- Contain the 'global' variable used by
`pkg-golang.mk`, `go-src/go-src.mk`, `go-bin/go-bin.mk`)
│  ├─ Config.in

Where `package/go/go.mk` is a virtual package that include the go variants:

```
HOST_GO_TARGET_ENV = \
...

HOST_GO_HOST_ENV = \
...

$(eval $(host-virtual-package))

include $(sort $(wildcard package/go/*/*.mk))
```

This solution won't change `pkg-golang.mk` but since it introduce a new way
to handle package variant I prefer to keep it for a next patch.

PERALE Thomas


On Mon, Oct 17, 2022 at 8:51 PM Christian Stewart <christian@paral.in>
wrote:

> Hi Yann,
>
> Just to reply to that one question on why a host go compiler is useful-
>
> On Mon, Oct 17, 2022 at 11:45 AM Yann E. MORIN <yann.morin.1998@free.fr>
> wrote:
> > >    - host go compiler (see patch linked below)
> >
> > If we have a pre-built host-go in the tree, thetre is then no reason to
> > be able to use the host system go compiler, is there?
>
> The host Go compiler may be compiled from source (i.e. Gentoo) and the
> user (me) wants to trust the gentoo binary for Go over downloading
> another precompiled bin from the internet.
>
> Thomas -
>
> On Mon, Oct 17, 2022 at 11:48 AM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >  - NodeJS (proposed by me)
> >    virtual package:             host-nodejs
> >    pre-compiled package:        host-nodejs-bin
> >    from source package:         host-nodejs-src
> >
> >    The odd thing here being that host-nodejs is a virtual package, but
> >    nodejs is a regular package building NodeJS from source for the
> >    target.
> >
> >  - Go (proposed by Thomas Perale)
> >    virtual package:             host-goc
> >    pre-compiled package:        host-go-bin
> >    from source package:         host-go
> >
> > So Thomas aligned on the naming used in the Rust world. I must say I do
> > have a preference for the naming I have chosen for NodeJS, which IMO is
> > clearer.
>
> I agree that the following would be preferable:
>
> virtual package:             host-go
> pre-compiled package:        host-go-bin
> from source package:         host-go-src
>
> ... although I would submit that all 3 could live in a single host-go
> package.
>
> Best,
> Christian Stewart
>

[-- Attachment #1.2: Type: text/html, Size: 4342 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot