[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 at 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 at 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.  |
'------------------------------^-------^------------------^--------------------'