Using MACHINE_FEATURES in a native recipe

Using MACHINE_FEATURES in a native recipe

[Andre McCurdy]

Currently native.bbclass clears MACHINEOVERRIDES but leaves
MACHINE_FEATURES alone. Is that an oversight? Or is there ever a
legitimate reason for a native recipe to have a dependency on
MACHINE_FEATURES?

Re: Using MACHINE_FEATURES in a native recipe

[Khem Raj]

On Wed, Mar 22, 2017 at 2:42 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> Currently native.bbclass clears MACHINEOVERRIDES but leaves
> MACHINE_FEATURES alone. Is that an oversight? Or is there ever a
> legitimate reason for a native recipe to have a dependency on
> MACHINE_FEATURES?

MACHINE_FEATURES is specific to target only.

> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Using MACHINE_FEATURES in a native recipe

[Andre McCurdy]

On Wed, Mar 22, 2017 at 2:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Wed, Mar 22, 2017 at 2:42 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> Currently native.bbclass clears MACHINEOVERRIDES but leaves
>> MACHINE_FEATURES alone. Is that an oversight? Or is there ever a
>> legitimate reason for a native recipe to have a dependency on
>> MACHINE_FEATURES?
>
> MACHINE_FEATURES is specific to target only.

Right, the question is really whether we should try to enforce that or not.

>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Using MACHINE_FEATURES in a native recipe

[Khem Raj]

On Wed, Mar 22, 2017 at 4:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
> On Wed, Mar 22, 2017 at 2:46 PM, Khem Raj <raj.khem@gmail.com> wrote:
>> On Wed, Mar 22, 2017 at 2:42 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>> Currently native.bbclass clears MACHINEOVERRIDES but leaves
>>> MACHINE_FEATURES alone. Is that an oversight? Or is there ever a
>>> legitimate reason for a native recipe to have a dependency on
>>> MACHINE_FEATURES?
>>
>> MACHINE_FEATURES is specific to target only.
>
> Right, the question is really whether we should try to enforce that or not.
>

we are better off to nullify it for native case. Worth a pull request :)

Re: Using MACHINE_FEATURES in a native recipe

[Richard Purdie]

On Wed, 2017-03-22 at 14:42 -0700, Andre McCurdy wrote:
> Currently native.bbclass clears MACHINEOVERRIDES but leaves
> MACHINE_FEATURES alone. Is that an oversight? Or is there ever a
> legitimate reason for a native recipe to have a dependency on
> MACHINE_FEATURES?

There is no good reason. Currently having this dilemma with
DISTRO_FEATURES too :/. 

opkg-native rebuilding if you enable/disable systemd isn't
expected/nice.

Cheers,

Richard

Re: Using MACHINE_FEATURES in a native recipe

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: den 23 mars 2017 17:43
> To: Andre McCurdy; OE Core mailing list
> Subject: Re: [OE-core] Using MACHINE_FEATURES in a native recipe
> 
> On Wed, 2017-03-22 at 14:42 -0700, Andre McCurdy wrote:
> > Currently native.bbclass clears MACHINEOVERRIDES but leaves
> > MACHINE_FEATURES alone. Is that an oversight? Or is there ever a
> > legitimate reason for a native recipe to have a dependency on
> > MACHINE_FEATURES?
> 
> There is no good reason. Currently having this dilemma with
> DISTRO_FEATURES too :/.
> 
> opkg-native rebuilding if you enable/disable systemd isn't
> expected/nice.
> 
> Cheers,
> 
> Richard

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.

//Peter

Re: Using MACHINE_FEATURES in a native recipe

[Richard Purdie]

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

Re: Using MACHINE_FEATURES in a native recipe

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@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

Re: Using MACHINE_FEATURES in a native recipe

[Jussi Kukkonen]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On 25 March 2017 at 17:34, Peter Kjellerstedt <peter.kjellerstedt@axis.com>
wrote:

> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@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.
>

It's possible but I've not found a single reason yet... If someone has a
hunch about a distro feature actually affecting a native tool, please
mention in https://bugzilla.yoctoproject.org/show_bug.cgi?id=11239

Jussi

[-- Attachment #2: Type: text/html, Size: 3157 bytes --]