Re: [OE-core][kirkstone 15/16] goarch: Move Go architecture mapping to a library

Steve Sakoman
2023-11-23T14:53:38Z

On Thu, Nov 23, 2023 at 3:45 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Thu, Nov 23, 2023 at 7:40 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Tue, 2023-11-21 at 16:31 -1000, Steve Sakoman wrote:
> > > From: Peter Marko <peter.marko@siemens.com>
> > >
> > > Other spaces uses the Go architecture definitions as their own (for
> > > example, container arches are defined to be Go arches). To make it
> > > easier for other places to use this mapping, move the code that does the
> > > translation of OpenEmbedded arches to Go arches to a library.
> > >
> > > (From oe-core rev: 3e86f72fc2e1cc2e5ea4b4499722d736941167ce)
> > >
> > > This commit together with meta-virtualization commit
> > > 115f6367f37095415f289fb6981cda9608ac72ff
> > > broke meta-virtualization master used with
> > > meta-lts-mixins kirkstone/go which is our primary
> > > usecase for having kirkstone/go mixin layer
> > >
> > > Manually crafted since cherry-pick had too many conflicts:
> > > * different path to classes
> > > * additional architecture loongarch64
> > > * different way how to import library
> > >
> > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > Cc: Joshua Watt <JPEWhacker@gmail.com>
> > > Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > Cc: Jose Quaresma <jose.quaresma@foundries.io>
> > > Signed-off-by: Steve Sakoman <steve@sakoman.com>
> > > ---
> > > meta/classes/base.bbclass | 2 +-
> > > meta/classes/goarch.bbclass | 27 +++------------------------
> > > meta/lib/oe/go.py | 32 ++++++++++++++++++++++++++++++++
> > > 3 files changed, 36 insertions(+), 25 deletions(-)
> > > create mode 100644 meta/lib/oe/go.py
> >
> > This did cause problems for some layers such as meta-virtualization so
> > I'd want to check those layers are ok with this?
> >
>
> It should be fine, the issues were around it not being present and recipes
> trying to use the mapping directly without the go.bbclass being inherited.
>
> It won't be used in kirkstone, so is a no-op there (for meta-virt), but that
> does mean some mixin and multi release compatible layers can more
> easily to backports.

Thanks for reviewing Richard and Bruce!

Since Bruce confirms there are no issues with meta-virt I'll leave
this in the series.

Steve