richard.purdie at linuxfoundation.org
Fri Jan 24 15:04:36 UTC 2020
On Fri, 2020-01-24 at 14:04 +0000, chris.laplante at agilent.com wrote:
> There are two main goals of this code. First, it sets up dependencies
> between -emscripten recipes. Second, it sets ‘prefix’ to be
> ‘/usr/js/’ so that, for example, a “foo” and “foo-emscripten” recipe
> that both install development headers won’t collide. I call this the
> 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.
> [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?
> [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.
More information about the Openembedded-core