From: Graeme Gregory <dp@xora.org.uk>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] base.bbclass: add support for SOC_FAMILY in COMPATIBLE_MACHINES
Date: Wed, 04 Aug 2010 17:59:30 +0100 [thread overview]
Message-ID: <4C599C72.10805@xora.org.uk> (raw)
In-Reply-To: <20100804161327.GA7189@denix.org>
On 04/08/10 17:13, Denys Dmytriyenko wrote:
> On Wed, Aug 04, 2010 at 12:48:38PM +0100, Phil Blundell wrote:
>> On Wed, 2010-08-04 at 13:17 +0200, Michael 'Mickey' Lauer wrote:
>>> FWIW, minimal is using MACHINE_CLASS since quite a while to
>>> reduce the need for adding the same files over and over again,
>>> this is being used e.g. for HTC msm7 series and OpenEZX series
>>> (see conf/machine/include).
>>>
>>> Perhaps it's time to standardize something like that.
>> Yeah. I certainly don't think we want a proliferation of such
>> mechanisms. If minimal is already using MACHINE_CLASS then there would
>> be some sense in trying to make use of the same thing.
>>
>> Failing that though, testing COMPATIBLE_MACHINE against MACHINE_CLASS
>> probably is more desirable than adding a completely new variable (i.e.
>> SOC_FAMILY) for that purpose.
> Phil,
>
> Re: "adding a completely new variable" - SOC_FAMILY has been in use for almost
> a year now. I'm hearing about MACHINE_CLASS for the first time, although it
> appears to be slightly older than SOC_FAMILY though. But it doesn't seem to be
> used anywhere besides in few machine configs and micro.conf. There are no
> recipes actually using it, unlike SOC_FAMILY...
>
> I'm not saying one is better than the other (actually, unifying them would
> be nice), I'm just saying it's too late to object adding SOC_FAMILY...
>
As the person who originally added MACHINE_CLASS to openmoko and the OE,
then removed it from OE I can say it has different meaning that
SOC_FAMILY. MACHINE_CLASS was to identify a range of machines that were
90% the same but had a few differences. It was used in a few recipes
which were MACHINE_ARCH to make them use the same ARCH in these recipes
to stop them being rebuilt when switching machines.
The original use was om-gta01 and om-gta02 which had the same MACHINE_CLASS.
Graeme
next prev parent reply other threads:[~2010-08-04 16:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-03 21:47 [PATCH] base.bbclass: add support for SOC_FAMILY in COMPATIBLE_MACHINES Chase Maupin
2010-08-04 0:19 ` Denys Dmytriyenko
2010-08-04 5:20 ` Khem Raj
2010-08-04 11:17 ` Michael 'Mickey' Lauer
2010-08-04 11:48 ` Phil Blundell
2010-08-04 14:11 ` Maupin, Chase
2010-08-04 16:50 ` Denys Dmytriyenko
2010-08-04 21:50 ` Phil Blundell
2010-08-04 16:13 ` Denys Dmytriyenko
2010-08-04 16:59 ` Graeme Gregory [this message]
2010-08-04 17:21 ` Denys Dmytriyenko
2010-08-04 19:41 ` Graeme Gregory
2010-08-04 9:13 ` Koen Kooi
2010-08-04 9:44 ` Frans Meulenbroeks
2010-08-04 19:02 ` Tom Rini
2010-08-04 9:54 ` Phil Blundell
2010-08-04 19:49 ` Khem Raj
2010-08-04 20:24 ` Maupin, Chase
2010-08-04 21:37 ` Khem Raj
2010-08-04 23:56 ` Koen Kooi
2010-08-05 4:38 ` Khem Raj
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=4C599C72.10805@xora.org.uk \
--to=dp@xora.org.uk \
--cc=openembedded-devel@lists.openembedded.org \
/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