[OE-core] Using MACHINE_FEATURES in a native recipe

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: den 25 mars 2017 11:27
> To: Peter Kjellerstedt; Andre McCurdy; OE Core mailing list
> Subject: Re: [OE-core] Using MACHINE_FEATURES in a native recipe
> 
> On Fri, 2017-03-24 at 15:10 +0000, Peter Kjellerstedt wrote:
> > Even though I agree this is a good change and that it should be done,
> > I wonder if we can either hold it off until after Pyro has been
> > released or make it possible to avoid it? The reason for this is that
> > I know that this change will require a huge amount of development
> > work for us, something that will not be possible to do in the time
> > frame left until Pyro is released. Or alternatively we will have to
> > copy native.bbclass to our layers and maintain a fork of it, which
> > sucks...
> >
> > The reason for this is that our unit test framework is based on
> > building all our own packages as native, but still configured via,
> > amongst others, MACHINE_FEATURES as if building for the real target.
> > This will of course not work anymore if MACHINE_FEATURES is set to ""
> > with no way of overriding it.
> 
> I'm afraid I only saw this after I merged it :(

No worries. I'll backport native.bbclass to our layers for now.

> I appreciate its a pain but I do think the change is the right thing to
> do (maybe with a corresponding DISTRO_FEATURES one too). Hopefully we
> can find a way that lets you work around it somehow...

I agree that cleaning MACHINE_FEATURES is the right thing to do. However, 
I am not so sure about DISTRO_FEATURES. After all, the native tools are 
part of the distro as well and there may be reasons to build them 
differently based on enabled features in the distro.

> Cheers,
> 
> Richard

//Peter