[Openembedded-architecture] Yocto Compatible 2.0 + signature changes
Joshua Watt
jpewhacker at gmail.com
Tue May 16 18:38:33 UTC 2017
> 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"
There are a lot of ways this mechanism could be activated
syntactically (either by applying it to whole files based on some
criteria, or using some directive in the bb file itself). I think it
might be worth discussing:
1) Is this something we even want to make an option (or should we
just make everyone append the overrides on all the variables manually)
2) What should the syntax mechanism be?
To that end, I've dug into the bitbake parsing code a little bit to
try and prototype out the basic "implict override" mechanism (which is
syntax independent at this point). I think getting a
quick-dirty-and-ugly implementation won't be too terribly hard, but I
haven't had a lot of time to look just yet.
Joshua Watt
More information about the Openembedded-architecture
mailing list