[OE-core] Custom CLASSOVERRIDE and a "sub-sysroot" for JavaScript

Richard Purdie richard.purdie at linuxfoundation.org
Fri Jan 24 16:03:27 UTC 2020


On Fri, 2020-01-24 at 15:26 +0000, chris.laplante at agilent.com wrote:
> Hi Richard,
> 
> > > I have a few concerns/questions:
> > > [a] Is the basic premise of a custom CLASSOVERRIDE supported by
> > > Yocto? Our situation seems a bit weird, because our emscripten
> > > recipes are still sort of “target” recipes, so I feel a bit funny
> > > completely wiping CLASSOVERRIDE.
> > 
> > I assume this class extension only applies for target recipes?
> > 
> > If so, why not append ":class-emscripten" to CLASSOVERRIDE rather
> > than
> > overwrite it? We support multiple overrides.
> 
> Makes sense, I'll give it a try. 
> 
> > > [b] At the very least, I know I did something wrong, because
> > > sometimes we get weird warnings like:
> > > 
> > > WARNING: app-emscripten-1.0+gitAUTOINC+1d1073e7c4-r0 do_compile:
> > > Manifest /home/user/yocto/build/tmp/sstate-control/manifest-
> > > x86_64_x86_64-nativesdk-library-emscripten.populate_sysroot not
> > > found
> > > in my_mach cortexa9t2hf-neon cortexa9t2hf-vfp cortexa9hf-neon
> > > cortexa9hf-vfp armv7at2hf-neon armv7ahf-neon armv7at2hf-vfp
> > > armv7ahf-
> > > vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp armv5ehf-vfp armv5thf-
> > > vfp
> > > armv5hf-vfp allarch x86_64_x86_64-nativesdk (variant '')?
> > > 
> > > ... usually followed by a build failure in “app-emscripten”
> > > because
> > > “library-emscripten:do_populate_sysroot” indeed didn’t run.
> > > Related
> > > to [a] or perhaps the stamp-extra-info lines?
> > 
> > I'd say the stamp-extra-info lines. Why do you think you want
> > those?
> 
> To be honest, I'm not completely sure. I based this class off of
> native.bbclass and nativesdk.bbclass and they both do it. I have
> little idea what stamp-extra-info actually does.  

My suggestion is not to do that. native and to a lesser extent
nativesdk are "special" in ways your class (being target related)
isn't.

Basically this code is how we were able to maintain a sysroot per
machine and pkgdata per machine.

The sysroot per machine is dead with recipe specific sysroots but today
we still have pkgdata shared per machine:

meta/classes/package.bbclass:do_packagedata[stamp-extra-info] = "${MACHINE_ARCH}"

which means the packagedata task will rerun per machine.

The nativesdk stamps only need to change per SDKMACHINE target (which
changes SDK_ARCH so we're fine there).

I'll try and remember to queue a cleanup for some bits of this as there
is a tiny bit of dead but harmless code.

Its in my queue to think about making pkgdata in WORKDIR then we could
ditch this whole thing.

> > > [c] Is there a better way to do the “sub-sysroot” (/usr/js)?
> > > Would
> > > multilib cover this whole use case?  (2)
> > 
> > No, it wouldn't since multilib assumes the headers are one set with
> > two
> > sets of binaries/libs. You are doing something quite similar to the
> > multilib class extension though.
> 
> OK, so the basic strategy seems OK then? 

I think so, but don't copy native/nativesdk! :) multlib is a better
reference (and doesn't do this with the stamps afaik).

Cheers,

Richard



More information about the Openembedded-core mailing list