On Fri, 2020-01-24 at 15:26 +0000, chris.lapla...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core