[Openembedded-architecture] Yocto Compatible 2.0 + signature changes
Patrick Ohly
patrick.ohly at intel.com
Thu May 11 09:59:46 UTC 2017
On Thu, 2017-05-11 at 10:03 +0100, Richard Purdie wrote:
> On Thu, 2017-05-11 at 08:54 +0200, Patrick Ohly wrote:
> > Alternatively, and probably better, is to allow "require/include"
> > statements without parameters. That is allowed for "inherit" already.
> > Once it is allowed, we could have a bar-my-former-bbappend.inc
> > alongside
> > bar_%.bbappend and include that conditionally, similar to the class
> > example above.
>
> Therefore I think I like this a lot more.
Me too.
> I'd certainly happily enhance
> bitbake to handle this case, it shouldn't be too difficult and we did
> this for classes already.
>From a practical side, having such a change backported to 2.3 might be
useful for layers who already want to become "Yocto Compatible 2.0" in a
branch targeting 2.3.
> There is one drawback to both approaches though, which is that post-
> parsing changes to the metadata won't have the desired effect. In
> particular, BBCLASSEXTEND is post-parsing. This means a native override
> on such a conditional file include may not work as you'd expect due to
> the point the override gets established. Effectively you're doing an
> expansion on OVERRIDES at the point you decide whether to include the
> file.
The main use case is to make .bbappends depend on global settings like
DISTRO_FEATURES. I know that even those do change between target and
native, but for the ones that control such basic build configuration
that can be disabled - see also my other mail about
distrooverrides.bbclass.
So I think this should work, it just needs good documentation that
captures the pros and cons of the different alternatives and their
limitations.
--
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