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

Richard Purdie richard.purdie at linuxfoundation.org
Thu Mar 17 21:02:33 UTC 2016


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 at intel.com
> > wrote:
> > 
> > On 17 March 2016 at 17:19, Andre McCurdy <armccurdy at 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.

We have made a decision to defaulting to introspection, rightly or
wrongly. I'm also quite happy to disable it where we know qemu can't
work and tune files are likely the right place to that.

I don't think this patchset is right.

Cheers,

Richard




More information about the Openembedded-core mailing list