[OE-core] [PATCH] uninative: add variables to the whitelist so that it does not re-triger recipe parsing

[Richard Purdie]

On Fri, 2018-03-30 at 12:45 +0000, Cuero Bugot wrote:
> > 
> > > 
> > > > 
> > > > On Fri, Mar 16, 2018 at 10:31 AM Cuero Bugot <mailto:cbugot at sie
> > > > rrawireless.com> wrote:
> > > > When uninative is activated (poky's default) internal
> > > > datastore 
> > > > variables are modified (NATIVELSBSTRING and
> > > > SSTATEPOSTUNPACKFUNCS) 
> > > > to enable uninative support. This is happening after parsing is
> > > > done at the beginning of the build. On the next bitbake call
> > > > the recipe would be parsed if the two variables above were not
> > > > added to the parsing whitelist BB_HASHCONFIG_WHITELIST.
> > > > 
> > > > The fix is to add these two variables to the recipe parsing 
> > > > whitelist BB_HASHCONFIG_WHITELIST, this is done at recipe
> > > > parsing time, only when uninative.bbclass is used.
> > > 
> > > It seems you have a case where data is already parsed and then 
> > > uninstive is enabled after this the reparse is happening. Or is
> > > it 
> > > always happening when uninative is enabled
> > It is always happening when uninative is enabled (which is poky's
> > default). The 2 first times you build you will have a full recipe
> > parsing.
> > The reason is that the data is effectively modified on reception of
> > BuildStarted event that happens after the parsing is done. Next
> > time you run bitbake, the datastore signature is different and thus
> > retrigger a recipe aprsing.
> Anything I could do help make merge-in this proposal?

Sorry about the delay, I wanted to check that we shouldn't be teaching
get_hash() in data_smart.py in bitbake something about excludevardeps
to make it work better.

In short the answer is that no, we shouldn't and your patch is the
better option. I've queued it in sumo-next. Thanks for figuring it out
as it is an annoying problem.

Cheers,

Richard