All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Mark Hatle <mark.hatle@kernel.crashing.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [v2 PATCH] base.bbclass: Add COMPATIBLE_OS, useful for non-Linux target recipes
Date: Thu, 26 Mar 2020 17:08:22 +0000	[thread overview]
Message-ID: <32f03631742205f4edb194b990e64661b42a1a6b.camel@linuxfoundation.org> (raw)
In-Reply-To: <27695.149.199.62.130.1585242305.squirrel@gate.crashing.org>

On Thu, 2020-03-26 at 12:05 -0500, Mark Hatle wrote:
> > On Thu, 2020-03-26 at 10:25 -0500, Mark Hatle wrote:
> > > Add the ability to generate non-Linux based components, such as
> > > baremetal, FreeRTOS, Zypher, etc, exist.  There is a need for a
> > > way
> > > to take components as specific to a given OS.
> > > 
> > > This is especially important in a multiconfig build where you may
> > > be
> > > targeting different OSes which different sets of recipes in a
> > > common
> > > set of layers.
> > > 
> > > Setting a default of (matching bitbake.conf's default TARGET_OS):
> > > 
> > >    COMPATIBLE_OS ?= "linux${LIBCEXTENSION}${ABIEXTENSION}"
> > > 
> > > will allow all existing recipes to be tagged as Linux specific,
> > > so
> > > only non-Linux recipes would need to be tagged with specific
> > > compatibility.
> > > 
> > > For a baremetal recipes, the following was used to test this
> > > code:
> > > 
> > >    COMPATIBLE_OS = "elf"
> > >    COMPATIBLE_OS_arm = "eabi"
> > > 
> > > Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
> > > ---
> > > V2:
> > > Only difference to V1 is typograhic fixes to the commit message.
> > > 
> > >  meta/classes/base.bbclass    | 7 +++++++
> > >  meta/conf/documentation.conf | 1 +
> > >  2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/meta/classes/base.bbclass
> > > b/meta/classes/base.bbclass
> > > index 45f9435fd8..c123c5dc50 100644
> > > --- a/meta/classes/base.bbclass
> > > +++ b/meta/classes/base.bbclass
> > > @@ -509,6 +509,13 @@ python () {
> > >          d.setVarFlag('do_devshell', 'fakeroot', '1')
> > >          d.appendVarFlag('do_devshell', 'depends', '
> > > virtual/fakeroot-native:do_populate_sysroot')
> > > 
> > > +    need_os = d.getVar('COMPATIBLE_OS')
> > > +    if need_os and not d.getVar('PARSE_ALL_RECIPES', False):
> > > +        import re
> > > +        this_os = d.getVar('TARGET_OS')
> > > +        if not re.match(need_os, this_os):
> > > +            raise bb.parse.SkipRecipe("incompatible with os %s
> > > (not
> > > in COMPATIBLE_OS)" % this_os)
> > > +
> > >      need_machine = d.getVar('COMPATIBLE_MACHINE')
> > >      if need_machine and not d.getVar('PARSE_ALL_RECIPES',
> > > False):
> > >          import re
> > > diff --git a/meta/conf/documentation.conf
> > > b/meta/conf/documentation.conf
> > > index 0b21d1f63e..7a87540f43 100644
> > > --- a/meta/conf/documentation.conf
> > > +++ b/meta/conf/documentation.conf
> > > @@ -111,6 +111,7 @@ COMBINED_FEATURES[doc] = "A set of features
> > > common between MACHINE_FEATURES and
> > >  COMMON_LICENSE_DIR[doc] = "Points to meta/files/common-licenses
> > > in
> > > the Source Directory, which is where generic license files
> > > reside."
> > >  COMPATIBLE_HOST[doc] = "A regular expression that resolves to
> > > one or
> > > more hosts (when the recipe is native) or one or more targets
> > > (when
> > > the recipe is non-native) with which a recipe is compatible."
> > 
> > How does COMPATIBLE_OS compare to COMPATIBLE_HOST (documented
> > above)?
> 
> HOST_SYS="aarch64-oe-linux"
> 
> So the equivalent to the COMPATIBLE_OS would be:
> 
> COMPATIBLE_HOST ?= ".*-linux.*"
> 
> So it COULD be used in most cases.
> 
> When I tried this before though, I could get it to work in a
> multiconfig
> setting.
> 
> Specifically what I tried was setting, in my local.conf:
> 
> COMPATIBLE_HOST ?= ".*-linux${LIBCEXTENSION}${ABIEXTENSION}"
> 
> And then in the recipes:
> 
> COMPATIBLE_HOST = ".*-elf"
> COMPATIBLE_HOST_arm = ".*-eabi"
> 
> But then the second one matches the linux ABIEXTENSION and broke..
> 
> So really the issue is that I -only- ever want to match on the OS
> part of
> the "SYS" string.  And done to the multiple natures of the '-', it's
> difficult to get right.
> 
> I didn't try something complex like: [^-]-[^-]-eabi

From what I remember, COMPATIBLE_HOST has full re support so something
should be possible...

Cheers,

Richard


  reply	other threads:[~2020-03-26 17:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26 15:25 [v2 PATCH] base.bbclass: Add COMPATIBLE_OS, useful for non-Linux target recipes Mark Hatle
2020-03-26 15:44 ` [OE-core] " Richard Purdie
2020-03-26 17:05   ` Mark Hatle
2020-03-26 17:08     ` Richard Purdie [this message]
     [not found]   ` <15FFE97B8BC33CAA.21883@lists.openembedded.org>
2020-03-26 19:20     ` Mark Hatle

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=32f03631742205f4edb194b990e64661b42a1a6b.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=mark.hatle@kernel.crashing.org \
    --cc=openembedded-core@lists.openembedded.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.