[oe] [PATCH] base.bbclass: fix soc-family test

Phil Blundell philb at gnu.org
Fri Sep 10 21:20:10 UTC 2010


On Fri, 2010-09-10 at 14:37 -0400, Denys Dmytriyenko wrote:
> I'd like us to find a compromise and a solution that satisfies everybody. 
> 
> Unfortunately, the original discussion about SOC_FAMILY vs. MACHINE_CLASS 
> never came to any fruition - Graeme explained his motives behind MACHINE_CLASS 
> and said that it is now deprecated.
> 
> It was also mentioned, while SOC_FAMILY is slightly newer than MACHINE_CLASS, 
> the feature itself is over a year old and used quite extensively, although 
> limited mainly to recipes/ti location...
> 
> And if technically SOC_FAMILY may be similar to MACHINE_CLASS, logically they 
> try to solve grouping problem from different direction, which was also 
> explained.
> 
> After that the original discussion was stalled and there were no strong 
> opinions one way or another. Based on that, Chase's change was pushed.
> 
> I see and understand Phil's position - if that's strong enough, we can 
> re-consider.

I take the point about MACHINE_CLASS and SOC_FAMILY being different in
intent.  However, I do feel that these are just two out of a whole
universe of possible machine groupings and I remain somewhat uneasy
about adding this sort of thing to base.bbclass: if we admit SOC_FAMILY
(or even MACHINE_CLASS) there then it seems like it will set an
undesirable precedent for the next guy who wants his favourite machine
grouping to be given the same treatment.  (The same thing applies to the
OVERRIDES patch that was posted recently and which I am not very fond of
either.)

How many recipes are there for which this is a big deal?  It's worth
remembering that the whole COMPATIBLE_MACHINE thing in base.bbclass is,
essentially, just syntactic sugar and there is nothing to stop you from
implementing whatever compatibility logic you want in your own .bb files
(or in an .inc, or a custom class).  If there are only a handful of
recipes for which gating on SOC_FAMILY is required then I would suggest
that you simply put the appropriate Python bits in those recipes.

p.






More information about the Openembedded-devel mailing list