On Tue, 2017-04-11 at 18:06 +0000, Peter Kjellerstedt wrote: > > > > -----Original Message----- > > From: Richard Purdie [mailto:richard.pur...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
