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. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
