Hi Damienm How about using BBMULTICONFIG ? https://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html#executing-a-multiple-configuration-build -- Takayasu Ito Technical Expert, Solution

Hi Damienm Conceptually, no. An image recipe is a recipe. Global data is global and local data is local. A recipe (image or package) set local data only. Correct way is different distro or machine.

No. Ross

Hi, Should it be possible to set PREFERRED_VERSION in the image definition files? I have 2 image files: - image1.bb - image2.bb : PREFERRED_VERSION_package_1.0.0 I have a package with 2 versions: -

Thanks for your answer. Yes I think it is the same SoC supplier since there is clang toolchain and they deliver it in a binary form and they have supplied an class for using it. I will look into the

Yeah i don't want to disable stripping the Target files. Well actually, I'll take a look at patching the tree with a custom CMakeLists.txt file. It may not be that bad. Thanks Ross

Putting files in the target sysroot that are in fact native binaries. Don't do that. Can you not work with upstream to integrate the changes? Alternatively, if the native parts are relatively simple,

What are some nasty hack options? The major surgery would be less maintainable.

A target recipe can't drop files into the native sysroot, so it's either nasty hacks or major surgery. Ross

Hi Ross, Yes I've done what you mention before. In this case I already have a Target and Native recipe. The Project generates a Native artifact when building the Target. Not resolvable without

Either use BBCLASSEXTEND or write a -native recipe, build just the native parts in a foo-native recipe and depend on that to build foo and other recipes. For example, glib-2.0 DEPENDS on

On Wed, May 13, 2020 at 09:53:12AM -0400, Robert P. J. Day wrote: [...] > > it gets weirder ... the project i'm working with is based on morty > so that variable *would* still be relevant, but even

it gets weirder ... the project i'm working with is based on morty so that variable *would* still be relevant, but even adding "Unlicense" to that variable didn't stop the offending recipe from

That'll teach me to check in master instead of my release of Yocto :) Quentin

that variable is gone: commit 64daaf29e2c12c8b587bafdebf9409433187ddf7 Author: Peter Kjellerstedt <peter.kjellerstedt@...> Date: Wed Dec 11 17:48:14 2019 +0100 licenses.conf:

Hi Robert, I'm not sure, but there might be a need to add it to SRC_DISTRIBUTE_LICENSES in openembedded-core/meta/conf/licenses.conf. Quentin

as long as this requires only adding an Unlicense file to that directory, i can do that shortly. rday

On Wed, 13 May 2020, Quentin Schulz wrote: ... snip ... > If it's really widely used, maybe something to add to > openembedded-core/files/common-licenses/ ? So that you don't need > any of the

... +1 for adding Unlicense to openembedded-core's common-licenses regards;rl

Hi Robert, You can add a license to your layer by doing the following in conf/layer.conf: LICENSE_PATH += "${LAYERDIR}/licenses" and in there you put the Unlicense file named exactly the same with