From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Andre McCurdy <armccurdy@gmail.com>,
"Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/8] bitbake.conf: remove 'gobject-introspection-data' from DISTRO/MACHINE_FEATURES_BACKFILL
Date: Thu, 17 Mar 2016 21:02:33 +0000 [thread overview]
Message-ID: <1458248553.7615.34.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAJ86T=X=amcjcvmsUidKYTsUYHMO+LHEE5znv-t0Qv8KGZLyjA@mail.gmail.com>
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.
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
next prev parent reply other threads:[~2016-03-17 21:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-17 17:19 [PATCH 0/8] gobject introspection fixes Andre McCurdy
2016-03-17 17:19 ` [PATCH 1/8] bitbake.conf: remove 'gobject-introspection-data' from DISTRO/MACHINE_FEATURES_BACKFILL Andre McCurdy
2016-03-17 17:31 ` Burton, Ross
2016-03-17 18:17 ` Andre McCurdy
2016-03-17 21:02 ` Richard Purdie [this message]
2016-03-18 11:08 ` Andre McCurdy
2016-03-21 14:15 ` Alexander Kanavin
2016-03-21 16:31 ` Richard Purdie
2016-03-17 17:19 ` [PATCH 2/8] default-distrovars.inc: add gobject-introspection-data to DISTRO_FEATURES_DEFAULT Andre McCurdy
2016-03-17 17:19 ` [PATCH 3/8] qemu.inc: add gobject-introspection-data to MACHINE_FEATURES Andre McCurdy
2016-03-17 17:19 ` [PATCH 4/8] arch-x86.inc: disable gobject introspection for x86-64 x32 builds Andre McCurdy
2016-03-17 17:19 ` [PATCH 5/8] qemuarm64.conf: don't clear MACHINE_FEATURES Andre McCurdy
2016-03-17 17:19 ` [PATCH 6/8] gobject-introspection.bbclass: wrap comments at 80 columns Andre McCurdy
2016-03-17 17:19 ` [PATCH 7/8] gobject-introspection.bbclass: make additional DEPENDS conditional Andre McCurdy
2016-03-17 17:29 ` Burton, Ross
2016-03-17 17:44 ` Andre McCurdy
2016-03-17 21:36 ` Martin Jansa
2016-03-17 22:16 ` Richard Purdie
2016-03-18 19:22 ` alexander.kanavin
2016-03-18 20:46 ` Martin Jansa
2016-03-17 17:19 ` [PATCH 8/8] gobject-introspection.bbclass: mark as machine specific due to COMBINED_FEATURES Andre McCurdy
2016-03-17 17:29 ` Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1458248553.7615.34.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=armccurdy@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox