2010/9/2 Michael 'Mickey' Lauer <[email protected]>: > Am Mittwoch, den 01.09.2010, 23:22 +0200 schrieb Leon Woestenberg: >> On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks >> <[email protected]> wrote: >> > Root cause: if SOC_FAMILY is not set (awhich is the case for most >> > MACHINEs and all distro's except angstrom) the test in base.bbclass >> > >> >> Good point, but I never understood SOC_FAMILY. From an old email: >> >> "SOC_FAMILY is defining a family of processors and the features that >> processor >> has. Whereas MACHINE_CLASS is defining a type of device and its features >> which >> can use different processors." >> >> I think the first sentence is contradicting itself. >> >> A "family of processors" vs. "features that processor had". This can >> be fully orthogonal (worst case), >> so the definition of the variable is crap. I wonder, has it proven >> more useful than cumbersome? > > I still don't know why we need both SOC_FAMILY and MACHINE_CLASS in the > first place. MACHINE_CLASS has been around for much longer and if you > look how it's being used or intended to use, you see that there are > hardly any processor differences in the members of those classes (e.g. > openezx, qualcomm msm7, om-gta01/02, clamshell zaurus models, ...). > > I'm still unconvinced that we need both variables.
Neither do I. Also it has been requested during the review (if I recall correctly by Tom) to provide documentation, but sadly enough that review comment was ignored and the change pushed anyway. Perhaps we should make explicit that the introduction of a new user var also must come with the associated documentation. Frans _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
