[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

Patrick Ohly patrick.ohly at intel.com
Fri May 12 07:34:13 UTC 2017


On Thu, 2017-05-11 at 21:17 -0500, Joshua Watt wrote:
> I think that one issue with the DISTRO_FEATURES/OVERRIDES mechanisms
> discussed might be the complication of simply writing a recipe
> correctly (as I think some people may have hinted at). Could this
> possible be solved with a more organizational approach? What if there
> were (is?) some way for this to be solved organizationally? Perhaps
> along these lines:
> 
>  # Add our recipes that don't change the signatures
>  BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
>  # Add the other appends that will change signatures...
>  # The user will have to ensure the proper overrides are set
>  BBFILES += "${LAYERDIR}/%OVERRIDE%/recipes-*/*/*.bbappend"
> 
> In this scheme, bitbake would expand %OVERRIDE% with the values from
> OVERRIDES (sort of like it does with FILESPATH). In this manner you
> can continue to write bbappend as you are used to, and use the
> filesystem organization to conditionally apply the bbappends based on
> the overrides. There are probably other similar mechanism that would
> work better, this one is mostly for illustration.

That would lead to a combinatorial explosion of potential paths that
would need to be checked when deciding whether to reparse, because the
actual file path most likely uses one or a few of the many overrides in
OVERRIDES. It's probably doable, just something to be aware of.

The same caveat as for the conditional include applies: only overrides
set in the base configuration can be used, and they must be the same for
all configurations in a multiconfig build.

My initial reaction was a bit doubtful, but I'm coming around to
agreeing that this might work.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.






More information about the Openembedded-architecture mailing list