[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

On Tue, 2017-05-09 at 09:42 +0100, Richard Purdie wrote:
> As you mention, there are some practicality issues associated with
> that. If this means we need to improve the technology we're using to
> handle those issues I'd be very open to that.

The override trick works to some extend, but there are cases where it
does not work:
      * addtask directive manipulating varflags ... and probably
        more ...

Anonymous Python code can do some of that after a suitable if check,
but that quickly becomes unreadable and unmaintainable.

I've come up with a more general approach that might be worth exploring
further:
      * copy the .bbappend content into a .bbclass
      * in the .bbappend: inherit
        ${@bb.utils.contains('DISTRO_FEATURES', 'foo',
        'bar-my-former-bbappend', d)}

The downside is that these pseudo-classes clutter the "classes"
directory. A natural place would be to put the .bbclass alongside
the .bbappend file, but that doesn't work, and the failure shows that
classes really are expected in a "classes" directory relative to the
BBFILES:

ERROR: ParseError at .../recipes-devtools/bmap-tools/bmap-tools_%.bbappend:1: Could not inherit file classes/bmap-tools-deploy.bbclass

This is where some enhancement for the class mechanism would be useful.

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.

I've also considered whether keeping a single .bbappend file with some
additional markup (think ifdef/endif) or some other extension where the
if condition for including the .bbappend file gets specified. I'm
undecided about both, as it is more intrusive.

-- 
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.