Re: Using MACHINE_FEATURES in a native recipe

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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 :(

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...

Cheers,

Richard