[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