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

[Thomas Perale]

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 at 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 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/
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20221017/cf788e4e/attachment-0001.html>