[OE-core] [PATCHv3 1/1] native/nativesdk: Use fixed DISTRO_FEATURES

[Richard Purdie]

On Tue, 2017-04-11 at 18:06 +0000, Peter Kjellerstedt wrote:
> > 
> > -----Original Message-----
> > From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
> > Se
> > On Tue, 2017-04-11 at 15:32 +0000, Peter Kjellerstedt wrote:
> > > 
> > > > +    # Set features here to prevent appends and distro features
> > > > backfill
> > > > +    # from modifying native distro features
> > > > +    features = set(d.getVar("DISTRO_FEATURES_NATIVE").split())
> > > > +    filtered = set(bb.utils.filter("DISTRO_FEATURES",
> > > > d.getVar("DISTRO_FEATURES_FILTER_NATIVE"), d).split())
> > > > +    d.setVar("DISTRO_FEATURES", " ".join(features | filtered))
> > > You should sort the list of features to make it deterministic.
> > Do we sort DISTRO_FEATURES anywhere else?
>
> No, but it is never worked upon via set() as these are here...
> 
> > 
> > I thought we only accessed DISTRO_FEATURES with functions which
> > have
> > support in bitbake (contains/filter) which means that should be
> > unnecessary?
>
> Will the lack of sorting not affect the task hashes (and bitbake -e)
> if these are set via set() operations, which may result in the order
> of the features listed in the final DISTRO_VARIABLE from varying
> based on how Python happens to pull the features out of the set()?

setVar operations don't actually affect task hashes directly. We track
functions which use variables through getVar/getVarFlag and only if
something uses it does its value affect the hash.

We can therefore safely setVar this, its only users of
getVar/getVarFlag which would see its value and with DISTRO_FEATURES,
we only obtain the value through contains/filter which have special
handling in bitbake (similar to getVar).

So I still think sorting is unnecessary, at least in theory.

Cheers,

Richard