Re: [PATCH 1/8] bitbake.conf: remove 'gobject-introspection-data' from DISTRO/MACHINE_FEATURES_BACKFILL

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

On Fri, 2016-03-18 at 04:08 -0700, Andre McCurdy wrote:
> On Thu, Mar 17, 2016 at 2:02 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2016-03-17 at 11:17 -0700, Andre McCurdy wrote:
> > > On Thu, Mar 17, 2016 at 10:31 AM, Burton, Ross <
> > > ross.burton@intel.com
> > > > wrote:
> > > > 
> > > > On 17 March 2016 at 17:19, Andre McCurdy <armccurdy@gmail.com>
> > > > wrote:
> > > > > 
> > > > > -DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5
> > > > > gobject-introspection-data"
> > > > > -MACHINE_FEATURES_BACKFILL = "rtc gobject-introspection-data"
> > > > > +DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5"
> > > > > +MACHINE_FEATURES_BACKFILL = "rtc"
> > > > 
> > > > So every BSP (apart from the qemu ones) would need to add the
> > > > feature to
> > > > MACHINE_FEATURES?
> > > > 
> > > > Maybe we should remove from DISTRO backfill but keep
> > > > backfilling
> > > > for MACHINE
> > > > features?
> > > 
> > > Or don't control via a MACHINE feature at all (which would also
> > > solve
> > > the package PACKAGE_ARCH issue) ?
> > > 
> > > Each CPU tuning file would then instead need to somehow express
> > > "this
> > > tuning target creates binaries which can / can't be run with
> > > qemu",
> > > but maybe that's an improvement too - isn't it better to define
> > > and
> > > maintain that information centrally in files controlled by oe
> > > -core
> > > rather than leave it up to BSPs to get right?
> > 
> > MACHINE_FEATURES is a variable which represents the features the
> > target
> > hardware has. There is nothing which says "this must be set in
> > MACHINE.conf". In fact there is significant precedent for setting
> > up
> > common include files which define the hardware properties.
> > 
> > If you look at one of my patches, it alters a core common include
> > file
> > to exclude introspection in a case where we can't use it (x32).
> > 
> > So I think we actually want the same thing which is for the common
> > tune
> > files to setup the right data.
> 
> Yes, I think so.
> 
> Deciding if/how qemu can run binaries for each tuning target is
> already partially addressed by the QEMU_EXTRAOPTIONS logic in
> qemu.bbclass. My suggestion would be to somehow generalise that
> existing logic, so (at least for machines using one of the standard
> oe-core tuning files) the question "can qemu run binaries created for
> ${MACHINE}?" could be answered automatically.

I think the "correct" way to do this is through MACHINE_FEATURES with
QEMU_EXTRAOPTIONS being used at the class level to sort out the flags
for qemu. The naming of the option within MACHINE_FEATURES is obviously
suboptimal at the moment though as Alex mentions.

I guess we did it this way since it meant we could easily use
COMBINED_FEATURES but we could have differently named options in there
at the cost of a bit of extra code.

Cheers,

Richard