a few questions about "COMPATIBLE_MACHINE" variable

a few questions about "COMPATIBLE_MACHINE" variable

[Robert P. J. Day]

  as a starting point, COMPATIBLE_MACHINE is processed on a per-recipe
basis, and if it has no value, then there is no machine restriction
being applied to that recipe, correct? that's based on this snippet
from base.bbclass:

  need_machine = d.getVar('COMPATIBLE_MACHINE')
  if need_machine:
      import re
      compat_machines = (d.getVar('MACHINEOVERRIDES') or "").split(":")
      for m in compat_machines:
          if re.match(need_machine, m):
              break
      else:
          raise bb.parse.SkipPackage("incompatible with machine %s (not in COMPATIBLE_MACHINE)" % d.getVar('MACHINE'))

so far, so good?

  next, the documentation describes the value of that variable as a
regular expression, so the values are processed as RE patterns, but
some of the actual uses are confusing. from
poky/meta/recipes-kernel/linux:

$ grep -r COMPATIBLE_MACHINE *
linux-dummy.bb:#COMPATIBLE_MACHINE = "your_machine"
linux-yocto_4.1.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
linux-yocto_4.4.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
linux-yocto_4.8.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
linux-yocto-dev.bb:COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
linux-yocto-rt_4.1.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
linux-yocto-rt_4.4.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
linux-yocto-rt_4.8.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
$

  first, what is best practice -- to use parentheses or not? i'm
assuming it makes no difference, but it does seem inconsistent and
could cause some confusion.

  next, if the possibilities in a list are REs, what is the point of
explicitly listing, say, "qemuarm|qemuarm64"? would not the RE
"qemuarm" subsume the more explicit "qemuarm64"? same for the other
architectures. (one could suggest that that entire line could be
shortened to "... = (^qemu)".)

  the above seems pretty clear since the following lines would appear
to say that *only* the qemux86 is compatible:

  linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
  linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
  linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"

which suggests the following passage from the YP kernel dev manual is
a bit misleading:

  "You must change it to match a list of the machines that your new
  recipe supports. For example, to support the qemux86 and qemux86-64
  machines, use the following form:

       COMPATIBLE_MACHINE = "qemux86|qemux86-64"

and if all this is true, then if you're introducing a new machine, to
be magnificently pedantic, one should not use:

  COMPATIBLE_MACHINE_machinename = "machinename"

but

  COMPATIBLE_MACHINE_machinename = "^machinename$"

just to play it safe. am i reading all this correctly?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: a few questions about "COMPATIBLE_MACHINE" variable

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 4058 bytes --]

On Mon, Dec 19, 2016 at 8:17 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

>   as a starting point, COMPATIBLE_MACHINE is processed on a per-recipe
> basis, and if it has no value, then there is no machine restriction
> being applied to that recipe, correct? that's based on this snippet
> from base.bbclass:
>
>   need_machine = d.getVar('COMPATIBLE_MACHINE')
>   if need_machine:
>       import re
>       compat_machines = (d.getVar('MACHINEOVERRIDES') or "").split(":")
>       for m in compat_machines:
>           if re.match(need_machine, m):
>               break
>       else:
>           raise bb.parse.SkipPackage("incompatible with machine %s (not
> in COMPATIBLE_MACHINE)" % d.getVar('MACHINE'))
>
> so far, so good?
>
>   next, the documentation describes the value of that variable as a
> regular expression, so the values are processed as RE patterns, but
> some of the actual uses are confusing. from
> poky/meta/recipes-kernel/linux:
>
> $ grep -r COMPATIBLE_MACHINE *
> linux-dummy.bb:#COMPATIBLE_MACHINE = "your_machine"
> linux-yocto_4.1.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|
> qemuppc|qemumips|qemumips64|qemux86-64"
> linux-yocto_4.4.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|
> qemuppc|qemumips|qemumips64|qemux86-64"
> linux-yocto_4.8.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|
> qemuppc|qemumips|qemumips64|qemux86-64"
> linux-yocto-dev.bb:COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|
> qemumips|qemumips64|qemux86-64)"
> linux-yocto-rt_4.1.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|
> qemuppc|qemumips)"
> linux-yocto-rt_4.4.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|
> qemuppc|qemumips)"
> linux-yocto-rt_4.8.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|
> qemuppc|qemumips)"
> linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
> linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
> linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
> $
>
>   first, what is best practice -- to use parentheses or not? i'm
> assuming it makes no difference, but it does seem inconsistent and
> could cause some confusion.
>

They’re not needed in a case like this.

  next, if the possibilities in a list are REs, what is the point of
> explicitly listing, say, "qemuarm|qemuarm64"? would not the RE
> "qemuarm" subsume the more explicit "qemuarm64"? same for the other
> architectures. (one could suggest that that entire line could be
> shortened to "... = (^qemu)".)
>

Just qemu would potentially match future qemu machines which aren’t
actually supported, so I don’t think that would be appropriate. It’d match
too much.

  the above seems pretty clear since the following lines would appear
> to say that *only* the qemux86 is compatible:
>
>   linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>   linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>   linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>
> which suggests the following passage from the YP kernel dev manual is
> a bit misleading:
>
>   "You must change it to match a list of the machines that your new
>   recipe supports. For example, to support the qemux86 and qemux86-64
>   machines, use the following form:
>
>        COMPATIBLE_MACHINE = "qemux86|qemux86-64"
>
> and if all this is true, then if you're introducing a new machine, to
> be magnificently pedantic, one should not use:
>
>   COMPATIBLE_MACHINE_machinename = "machinename"
>
> but
>
>   COMPATIBLE_MACHINE_machinename = "^machinename$"
>
> just to play it safe. am i reading all this correctly?
>

Yes, that’s correct, though we need the trailing $ but not the leading ^,
as it’s using re.match, not re.search — meaning it only matches at the
beginning of the string, it doesn’t search the string to find a match.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 5476 bytes --]

Re: a few questions about "COMPATIBLE_MACHINE" variable

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 5187 bytes --]


On Mon, 19 Dec 2016, Christopher Larson wrote:

> On Mon, Dec 19, 2016 at 8:17 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>         as a starting point, COMPATIBLE_MACHINE is processed on a
>       per-recipe basis, and if it has no value, then there is no
>       machine restriction being applied to that recipe, correct?
>       that's based on this snippet from base.bbclass:
>
>         need_machine = d.getVar('COMPATIBLE_MACHINE')
>         if need_machine:
>             import re
>             compat_machines = (d.getVar('MACHINEOVERRIDES') or "").split(":")
>             for m in compat_machines:
>                 if re.match(need_machine, m):
>                     break
>             else:
>                 raise bb.parse.SkipPackage("incompatible with machine %s (not in COMPATIBLE_MACHINE)" %
>       d.getVar('MACHINE'))
>
>       so far, so good?
>
>         next, the documentation describes the value of that variable
>       as a regular expression, so the values are processed as RE
>       patterns, but some of the actual uses are confusing. from
>       poky/meta/recipes-kernel/linux:
>
>       $ grep -r COMPATIBLE_MACHINE *
>       linux-dummy.bb:#COMPATIBLE_MACHINE = "your_machine"
>       linux-yocto_4.1.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
>       linux-yocto_4.4.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
>       linux-yocto_4.8.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
>       linux-yocto-dev.bb:COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
>       linux-yocto-rt_4.1.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
>       linux-yocto-rt_4.4.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
>       linux-yocto-rt_4.8.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
>       linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       $
>
>         first, what is best practice -- to use parentheses or not?
>       i'm assuming it makes no difference, but it does seem
>       inconsistent and could cause some confusion.
>
> They’re not needed in a case like this. 

i suspected as much. still, would consistency dictate using
parentheses or not? just a style thing.

>       next, if the possibilities in a list are REs, what is the
>       point of explicitly listing, say, "qemuarm|qemuarm64"? would
>       not the RE "qemuarm" subsume the more explicit "qemuarm64"?
>       same for the other architectures. (one could suggest that that
>       entire line could be shortened to "... = (^qemu)".)
>
> Just qemu would potentially match future qemu machines which aren’t
> actually supported, so I don’t think that would be appropriate. It’d
> match too much.

  i realized that, i was just being technical. :-) in any event, as it
is, it would *still* match too much, anything starting with
"qemuarm", for example.

>         the above seems pretty clear since the following lines would appear
>       to say that *only* the qemux86 is compatible:
>
>         linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>         linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>         linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>
>       which suggests the following passage from the YP kernel dev manual is
>       a bit misleading:
>
>         "You must change it to match a list of the machines that your new
>         recipe supports. For example, to support the qemux86 and qemux86-64
>         machines, use the following form:
>
>              COMPATIBLE_MACHINE = "qemux86|qemux86-64"
>
>       and if all this is true, then if you're introducing a new machine, to
>       be magnificently pedantic, one should not use:
>
>         COMPATIBLE_MACHINE_machinename = "machinename"
>
>       but
>
>         COMPATIBLE_MACHINE_machinename = "^machinename$"
>
>       just to play it safe. am i reading all this correctly?
>
>
> Yes, that’s correct, though we need the trailing $ but not the
> leading ^, as it’s using re.match, not re.search — meaning it only
> matches at the beginning of the string, it doesn’t search the string
> to find a match.

  ah, quite right, i had forgotten that. again, in any event, both the
code and documentation could probably be tweaked to make all of this
more obvious.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: a few questions about "COMPATIBLE_MACHINE" variable

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]

On Mon, Dec 19, 2016 at 10:56 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:

> i suspected as much. still, would consistency dictate using
> parentheses or not? just a style thing.
>

I think it’s largely personal preference. Personally, using a capture when
we don’t need one is ugly to me, so I’d rather see it only used when
needed, but that’s just my opinion. The upside to always using a capture is
it makes it clearer, at a glance, to a new user that it’s not just a word
or list of words, but a regular expression.


> >       next, if the possibilities in a list are REs, what is the
> >       point of explicitly listing, say, "qemuarm|qemuarm64"? would
> >       not the RE "qemuarm" subsume the more explicit "qemuarm64"?
> >       same for the other architectures. (one could suggest that that
> >       entire line could be shortened to "... = (^qemu)".)
> >
> > Just qemu would potentially match future qemu machines which aren’t
> > actually supported, so I don’t think that would be appropriate. It’d
> > match too much.
>
>   i realized that, i was just being technical. :-) in any event, as it
> is, it would *still* match too much, anything starting with
> "qemuarm", for example.
>

Good point, yes.

>         the above seems pretty clear since the following lines would
> appear
> >       to say that *only* the qemux86 is compatible:
> >
> >         linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
> >         linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
> >         linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
> >
> >       which suggests the following passage from the YP kernel dev manual
> is
> >       a bit misleading:
> >
> >         "You must change it to match a list of the machines that your new
> >         recipe supports. For example, to support the qemux86 and
> qemux86-64
> >         machines, use the following form:
> >
> >              COMPATIBLE_MACHINE = "qemux86|qemux86-64"
> >
> >       and if all this is true, then if you're introducing a new machine,
> to
> >       be magnificently pedantic, one should not use:
> >
> >         COMPATIBLE_MACHINE_machinename = "machinename"
> >
> >       but
> >
> >         COMPATIBLE_MACHINE_machinename = "^machinename$"
> >
> >       just to play it safe. am i reading all this correctly?
> >
> >
> > Yes, that’s correct, though we need the trailing $ but not the
> > leading ^, as it’s using re.match, not re.search — meaning it only
> > matches at the beginning of the string, it doesn’t search the string
> > to find a match.
>
>   ah, quite right, i had forgotten that. again, in any event, both the
> code and documentation could probably be tweaked to make all of this
> more obvious.
>

Absolutely agreed. For this regex specifically, an argument could be made
that a lack of a trailing $ is almost certainly a bug. I could argue that
it should either be implicit, though that would be limiting, or failing to
include it could trigger a warning unless you explicitly state you know
what you’re doing :) Hmm..
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 4631 bytes --]

Re: a few questions about "COMPATIBLE_MACHINE" variable

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 4699 bytes --]

On Mon, 19 Dec 2016, Christopher Larson wrote:

> On Mon, Dec 19, 2016 at 10:56 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       i suspected as much. still, would consistency dictate using
>       parentheses or not? just a style thing.
>
>
> I think it’s largely personal preference. Personally, using a
> capture when we don’t need one is ugly to me, so I’d rather see it
> only used when needed, but that’s just my opinion. The upside to
> always using a capture is it makes it clearer, at a glance, to a new
> user that it’s not just a word or list of words, but a regular
> expression.

  i can see both sides, but my concern (as it always is) is
consistency. when beginners are starting out, it's tempting to RTFS to
see how things are done, and if you see more than one style, there's
the potential for confusion as the poor reader thinks, "is there a
*reason* the same thing is being done two different ways? is there
something magical about those parentheses that the documentation
doesn't explain?"

  i realize that (as with perl) there's more than one way to do
things. doesn't mean we need to.

>       >       next, if the possibilities in a list are REs, what is the
>       >       point of explicitly listing, say, "qemuarm|qemuarm64"? would
>       >       not the RE "qemuarm" subsume the more explicit "qemuarm64"?
>       >       same for the other architectures. (one could suggest that that
>       >       entire line could be shortened to "... = (^qemu)".)
>       >
>       > Just qemu would potentially match future qemu machines which aren’t
>       > actually supported, so I don’t think that would be appropriate. It’d
>       > match too much.
>
>         i realized that, i was just being technical. :-) in any event, as it
>       is, it would *still* match too much, anything starting with
>       "qemuarm", for example.
>
> Good point, yes. 
>
>       >         the above seems pretty clear since the following lines would appear
>       >       to say that *only* the qemux86 is compatible:
>       >
>       >         linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       >         linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       >         linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       >
>       >       which suggests the following passage from the YP kernel dev manual is
>       >       a bit misleading:
>       >
>       >         "You must change it to match a list of the machines that your new
>       >         recipe supports. For example, to support the qemux86 and qemux86-64
>       >         machines, use the following form:
>       >
>       >              COMPATIBLE_MACHINE = "qemux86|qemux86-64"
>       >
>       >       and if all this is true, then if you're introducing a new machine, to
>       >       be magnificently pedantic, one should not use:
>       >
>       >         COMPATIBLE_MACHINE_machinename = "machinename"
>       >
>       >       but
>       >
>       >         COMPATIBLE_MACHINE_machinename = "^machinename$"
>       >
>       >       just to play it safe. am i reading all this correctly?
>       >
>       >
>       > Yes, that’s correct, though we need the trailing $ but not the
>       > leading ^, as it’s using re.match, not re.search — meaning it only
>       > matches at the beginning of the string, it doesn’t search the string
>       > to find a match.
>
>         ah, quite right, i had forgotten that. again, in any event, both the
>       code and documentation could probably be tweaked to make all of this
>       more obvious.
>
> Absolutely agreed. For this regex specifically, an argument could be
> made that a lack of a trailing $ is almost certainly a bug. I could
> argue that it should either be implicit, though that would be
> limiting, or failing to include it could trigger a warning unless
> you explicitly state you know what you’re doing :) Hmm..

  well, regardless of any tweaking, i think the docs need to be far
more clear on the processing of COMPATIBLE_MACHINE.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: a few questions about "COMPATIBLE_MACHINE" variable

[Robert P. J. Day]

[-- Attachment #1: Type: text/plain, Size: 4993 bytes --]


  (following up on a short discussion from back in december on proper
setting for COMPATIBLE_MACHINE ...)

On Mon, 19 Dec 2016, Christopher Larson wrote:

>
> On Mon, Dec 19, 2016 at 10:56 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       i suspected as much. still, would consistency dictate using
>       parentheses or not? just a style thing.
>
>
> I think it’s largely personal preference. Personally, using a
> capture when we don’t need one is ugly to me, so I’d rather see it
> only used when needed, but that’s just my opinion. The upside to
> always using a capture is it makes it clearer, at a glance, to a new
> user that it’s not just a word or list of words, but a regular
> expression.
>  
>       >       next, if the possibilities in a list are REs, what is the
>       >       point of explicitly listing, say, "qemuarm|qemuarm64"? would
>       >       not the RE "qemuarm" subsume the more explicit "qemuarm64"?
>       >       same for the other architectures. (one could suggest that that
>       >       entire line could be shortened to "... = (^qemu)".)
>       >
>       > Just qemu would potentially match future qemu machines which aren’t
>       > actually supported, so I don’t think that would be appropriate. It’d
>       > match too much.
>
>         i realized that, i was just being technical. :-) in any event, as it
>       is, it would *still* match too much, anything starting with
>       "qemuarm", for example.
>
>
> Good point, yes. 
>
>       >         the above seems pretty clear since the following lines would appear
>       >       to say that *only* the qemux86 is compatible:
>       >
>       >         linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       >         linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       >         linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
>       >
>       >       which suggests the following passage from the YP kernel dev manual is
>       >       a bit misleading:
>       >
>       >         "You must change it to match a list of the machines that your new
>       >         recipe supports. For example, to support the qemux86 and qemux86-64
>       >         machines, use the following form:
>       >
>       >              COMPATIBLE_MACHINE = "qemux86|qemux86-64"
>       >
>       >       and if all this is true, then if you're introducing a new machine, to
>       >       be magnificently pedantic, one should not use:
>       >
>       >         COMPATIBLE_MACHINE_machinename = "machinename"
>       >
>       >       but
>       >
>       >         COMPATIBLE_MACHINE_machinename = "^machinename$"
>       >
>       >       just to play it safe. am i reading all this correctly?
>       >
>       >
>       > Yes, that’s correct, though we need the trailing $ but not the
>       > leading ^, as it’s using re.match, not re.search — meaning it only
>       > matches at the beginning of the string, it doesn’t search the string
>       > to find a match.
>
>         ah, quite right, i had forgotten that. again, in any event, both the
>       code and documentation could probably be tweaked to make all of this
>       more obvious.
>
>
> Absolutely agreed. For this regex specifically, an argument could be
> made that a lack of a trailing $ is almost certainly a bug. I could
> argue that it should either be implicit, though that would be
> limiting, or failing to include it could trigger a warning unless
> you explicitly state you know what you’re doing :) Hmm..

  i'm following up only because i'm going through the YP kernel-dev
manual, and it contains the following snippet:

    For example, to support the qemux86 and qemux86-64 machines, use
    the following form:

     COMPATIBLE_MACHINE = "qemux86|qemux86-64"

which, as chris explained, because matching uses python's "re.match"
operator, already anchors the search string at the beginning but not
at the end so, technically and pedantically, it could be assigned
equally well with (at least for the moment):

     COMPATIBLE_MACHINE = "qemux86"

or, more precisely:

     COMPATIBLE_MACHINE = "qemux86$|qemux86-64$"

is there a style guide entry for proper use of COMPATIBLE_MACHINE?
having the manuals make suggestions that are potentially confusing
to inexperienced users seems like a bad idea.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: a few questions about "COMPATIBLE_MACHINE" variable

[Robert P. J. Day]

On Sun, 26 Feb 2017, Robert P. J. Day wrote:

... big snip ...

> is there a style guide entry for proper use of COMPATIBLE_MACHINE?
> having the manuals make suggestions that are potentially confusing
> to inexperienced users seems like a bad idea.

  for fun, i did a quick grep in the oe-core layer:

meta/conf/documentation.conf:COMPATIBLE_MACHINE[doc] = "A regular expression that resolves to one or more target machines with which a recipe is compatible."
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb:COMPATIBLE_MACHINE = "(qemux86$)"
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb:COMPATIBLE_MACHINE = "(qemux86$)"
meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
meta/recipes-kernel/linux/linux-yocto_4.4.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
meta/recipes-kernel/linux/linux-yocto-dev.bb:COMPATIBLE_MACHINE = "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64)"
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb:COMPATIBLE_MACHINE = "(qemux86$)"
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb:COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)"
meta/recipes-kernel/linux/linux-dummy.bb:#COMPATIBLE_MACHINE = "your_machine"
meta/recipes-kernel/linux/linux-yocto_4.9.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
meta/recipes-kernel/linux/linux-yocto_4.1.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
meta/recipes-kernel/linux/linux-yocto_4.8.bb:COMPATIBLE_MACHINE = "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb:COMPATIBLE_MACHINE = "(qemux86$)"
meta/classes/base.bbclass:    need_machine = d.getVar('COMPATIBLE_MACHINE')
meta/classes/base.bbclass:            raise bb.parse.SkipPackage("incompatible with machine %s (not in COMPATIBLE_MACHINE)" % d.getVar('MACHINE'))

  so as long as i understand correctly the re.match() anchoring, some
of the above assignments can definitely be tightened up with no change
in behaviour, correct? not saying i'm going to run off and submit a
patch for that, since i rather like chris' suggestion that the
matching be tightened up to catch inadvertently sloppy matching, as
long as that doesn't break all kinds of stuff.

  thoughts?

rday

p.s. hey, COMPATIBLE_HOST seems to work the same way, so it seems
there would be no value in appending ".*" to the end of any choice so,
for example:

  argp-standalone_1.3.bb:COMPATIBLE_HOST = ".*-musl.*"

could be more simply written as:

  argp-standalone_1.3.bb:COMPATIBLE_HOST = ".*-musl"

yes?

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================