On Mon, Feb 27, 2017 at 10:53 AM, Robert P. J. Day <[email protected]> wrote: > On Mon, 27 Feb 2017, Phil Blundell wrote: > >> On Mon, 2017-02-27 at 09:09 -0500, Robert P. J. Day wrote: >> > # webkit-efl isn't available for < armv7a >> > COMPATIBLE_MACHINE = "(-)" >> > COMPATIBLE_MACHINE_x86 = "(.*)" >> > COMPATIBLE_MACHINE_x86-64 = "(.*)" >> > COMPATIBLE_MACHINE_armv7a = "(.*)" >> > >> > first, that comment seems out of date as it makes no mention of >> > MIPS >> > or ppc, but that's just being picky. >> > >> > next, i assume the line: >> > >> > COMPATIBLE_MACHINE = "(-)" >> > >> > is to initialize the set of compatible machines to the empty set, >> > yes? >> >> I think the intent is to set it to a string that "can't possibly >> ever match". > > right, that's what i suspected. > >> > >> i next assume that lines of the form: >> > >> > COMPATIBLE_MACHINE_x86 = "(.*)" >> > >> > are meant to indicate that if that MACHINE_OVERRIDES comparison >> > succeeds, then all possible targets are compatible, is that right? >> > however, given precisely those lines above, is it not equivalent to >> > just write: >> > >> > COMPATIBLE_MACHINE = "(x86|x86-64|armv7a)" >> >> No, because "armv7a" is not a MACHINE. It would be more equivalent >> to write >> >> COMPATIBLE_HOST = "armv7a-.*" >> >> but even this would not be quite the same because it would fail to >> match "cortexa15-linux" for example. Actually that's not a very >> good example because cortexa15 is armv7ve not armv7a, but you get >> the idea. > > i'm going to disagree here, i never suggested "armv7a" was a > "machine" (in the sense of having a defining armv7a.conf file). i said > it was part of MACHINE_OVERRIDES, and therefore *would* be considered > a matching "machine" for the purposes of COMPATIBLE_MACHINE. > > as another example, there is no such machine as a "qoriq", but that > is considered a valid choice for COMPATIBLE_MACHINE since several > actual machine definition files do this: > > MACHINEOVERRIDES =. "qoriq:" > > am i making sense?
I think so. However, note that ARM is somewhat of a special case in that it includes over-rides derived from TUNE_FEATURES in MACHINEOVERRIDES (although MIPS has recently started to do so too). In the general case (and especially in the context of COMPATIBLE_MACHINE) it's probably better to think of MACHINEOVERRIDES as containing just the machine name and perhaps a SOC family. (Maybe it would be clearer if over-rides derived from TUNE_FEATURES were placed in a dedicated variable, e.g. TUNINGOVERRIDES, rather than being crammed into MACHINEOVERRIDES?). > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
