All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gunnar Andersson <gandersson@genivi.org>
To: Takashi Matsuzawa <tmatsuzawa@xevo.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: "(-)"??
Date: Thu, 21 Sep 2017 22:40:31 +0200	[thread overview]
Message-ID: <1506026431.8543.59.camel@genivi.org> (raw)
In-Reply-To: <CA+chaQcCvMNZ7AJ_=v52EHDYgXeW09tm8n8FuTu9CGrFcMZphw@mail.gmail.com>


On Thu, 2017-09-21 at 12:43 +0200, Martin Jansa wrote:
> null and nothing can also be matched in MACHINE names, so to make sure
> people should use:
> 
> COMPATIBLE_MACHINE = "(^$)"
> 
[trimmed]
> > >
> > > COMAPTIBLE_MACHINE uses regexp syntax
> > 
> > Which actually makes that a pretty weird COMPATIBLE_MACHINE,
> > 
> > especially if it is intended for blacklisting.

Yes, I think seeking consensus on the best practice here would make a lot of
sense.  Clearly people copy each other, but there are still *so* many
variants of this out there!

Very often machine overrides are used because there's no real sane way of
adding a specific machine, to the value that is there already:

This is actually written in many places:

COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"

So if I see it correctly, that's going to apply if and only if MACHINE is
core2-32-intel-common and if so, then the ${MACHINE} regexp will also expand
to "core2-32-intel-common", and then finally bitbake will match that (as a
regexp) against the same $MACHINE name again to see if it yields true
(which it always will)...  I mean it's a little crazy isn't it?

Luckily special characters are usually not used in the machine names, or the
above might have unintended consequences too.

Sometimes the pattern matching is good but most of the time we just to say
basically: IS_COMPATIBLE(mymachinename)!

There are also these variations in various layers:

COMPATIBLE_MACHINE_genericx86 = "genericx86"

and this one seems popular:

# (Always match my string, but using MACHINE override):
COMPATIBLE_MACHINE_x86-64 = "(.*)"

That's a bit more straight forward, but not much.

If it's a true regexp match as Martin indicates with the ^$ example to
exclude non-empty string - presumably then, this syntax is yet another
working alternative because an empty regexp matches, right?

COMPATIBLE_MACHINE_x86-64 = ""

Being able to append your new machine in a sane way would make sense, but
with regexps it seems the reasonable syntax would then be:

COMPATIBLE_MACHINE_append = "|core2-32-intel-common"

Is that right?  And is that syntax also being used?  I'm not sure if that
will result in a valid regexp 100% of the time, but presumably it might
work.

And what is this?  I'm not sure I understand this one...

COMPATIBLE_MACHINE_{{=machine}} = "{{=machine}}"


There is legacy and compatibility to consider I understand, but just looking
at it with fresh eyes, this thing seems to beg for a more easy to understand
mechanism.

I wonder if what one might like is a kind of array (of regexps), so you can
add new machines or machine-patterns to it in a sane manner.  Admittedly it
makes it harder to reset/subtract from the value if you want to remove some
previous setting.

Perhaps in a new design I'd consider two mechanisms, one for exact matches,
which could act as a list of words - many other bitbake variables do - and
one for patterns:

COMPATIBLE_MACHINE_EXACT = "first-machine second-machine"
COMPATIBLE_MACHINE_EXACT += " third-machine"

COMPATIBLE_MACHINE_PATTERN = "(.*x86.*)"

Just my 2c, take it for what it's worth.

- Gunnar

-- 
Gunnar Andersson <gandersson@genivi.org>
Development Lead
GENIVI Alliance





  reply	other threads:[~2017-09-21 20:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21  3:18 "(-)"?? Takashi Matsuzawa
2017-09-21  5:15 ` "(-)"?? Khem Raj
2017-09-21  6:41   ` "(-)"?? Peter Kjellerstedt
2017-09-21 10:43     ` "(-)"?? Martin Jansa
2017-09-21 20:40       ` Gunnar Andersson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-04-23 17:45 :-) linux-net
     [not found] <vhscbyaxijufnolotqo@scyld.com>
2004-03-26  9:51 ` :-) P
2002-03-17  1:14 ±±¾©Ë÷ÁèÀñÆ·ÖÐÐÄ-ÀñÆ·¡¢°ì¹«ÓÃÆ·¡¢¼ÒÍ¥ÓÃÆ·¡¢´ÙÏúÆ·¡¢¹ã¸æÉ¡¡¢ÀñÆ·±í¡¢¹ã¸æ±Ê ±±¾©Ë÷ÁèÀñÆ·ÖÐÐÄ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1506026431.8543.59.camel@genivi.org \
    --to=gandersson@genivi.org \
    --cc=tmatsuzawa@xevo.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.