[Openembedded-architecture] Yocto Compatible 2.0 + signature changes

[Patrick Ohly]

On Tue, 2017-05-16 at 13:38 -0500, Joshua Watt wrote:
> > I've been thinking about this. The code that does this for SRC_URI is
> > quite complex and potentially problematic as it stands. The idea above
> > would entwine that with the parser and I'm not sure it can be made to
> > work in a way which wouldn't avoid circular dependency issues or behave
> > in a way which the user expects. Therefore, whilst I can see the
> > attraction, I'm not sure its something we'd want to do.
> 
> I've been think about this and came to some conclusions: We probably
> don't want to do it exactly this way (i.e. conditionally parsing
> files) for some of the reasons described. While thinking about it, I
> came to the conclusions that pretty much all the approaches boil down
> to doing the same thing: adding implicit overrides to a set of
> variable.
>
>  The basic idea of what we want is something like this
> (please note, I'm not proposing this as the actual syntax, it's just
> an example):
> 
> push override "foo"
> DEPENDS += "libbar"
> SRC_URI_append = "file://foo"
> pop override
> 
> # The above is syntactically equivalent to:
> # DEPENDS_foo += "libbar"
> # SRC_URI_append_foo += "file://foo"

This example is a bit misleading, because we cannot map everything that
might appear between push/pop (or whatever the syntax ends up to be) to
some equivalent code, because there are things which have no conditional
equivalent (for example, "addtask").

So such conditional sections can only be mapped to conditional includes.
That might be nicer than having to create some extra include file, but
it all hinges on the specific syntax. I'm not sure whether it's worth
the additional complexity.

My preferred solution at this time is:
     1. enhancing require/include so that they work without parameter
     2. some common mechanism for mapping DISTRO_FEATURES to overrides

I'll post my solution for 2 tomorrow on the OE-core list. We can discuss
the code there.

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