[OE-core] a few more picky questions about COMPATIBLE_MACHINE usage

Andre McCurdy armccurdy at gmail.com
Mon Feb 27 19:49:45 UTC 2017


On Mon, Feb 27, 2017 at 10:53 AM, Robert P. J. Day
<rpjday at crashcourse.ca> 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
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



More information about the Openembedded-core mailing list