Re: Debug from failing hashequiv builds - server side problem?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sun, 2019-12-22 at 10:22 -0600, Joshua Watt wrote:
> On Sun, Dec 22, 2019, 10:17 AM Joshua Watt <jpewhacker@gmail.com>
> wrote:
> > 
> > On Sun, Dec 22, 2019, 10:09 AM Richard Purdie <
> > richard.purdie@linuxfoundation.org> wrote:
> > > On Sun, 2019-12-22 at 10:00 -0600, Joshua Watt wrote:
> > > It won't help the other native/cross to target boundary mapping
> > > issue.
> > > 
> > > See above, I'm wondering if we could abuse the method field to
> > > make
> > > this work? Certainly we could test that...
> > 
> > That seems reasonable for a quick test. The method is supposed to
> > be the output hash calculation method, so my first instinct would
> > be that it is better in the long run to add another field e.g.
> > "class" or something.
> 
> Perhaps based on ${NATIVELSBSTRING} like sstate.bbclass path? That
> has nice congruency with sstate file paths, which I like

If only that were the right thing.

We need:

    if bb.data.inherits_class('native', d):
        d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
    elif bb.data.inherits_class('cross', d):
        d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))

i.e. SSTATE_PKGARCH but only for native/cross.

Cheers,

Richard