public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>,
	 "openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings
Date: Mon, 16 Mar 2026 11:28:54 +0000	[thread overview]
Message-ID: <3f73b46c12aff52292d488f48d11572c66991b70.camel@linuxfoundation.org> (raw)
In-Reply-To: <DB5PR02MB10213C75B95E2CBE99D91221DEF40A@DB5PR02MB10213.eurprd02.prod.outlook.com>

On Mon, 2026-03-16 at 11:21 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From:
> > openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org
> > > On Behalf Of Richard Purdie via lists.openembedded.org
> > Sent: den 14 mars 2026 11:27
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package
> > architectures into layer.conf settings
> > 
> > Other layers need to be able to add dummy recipes. To do this add
> > DUMMY_PACKAGE_ARCHS_SDK and DUMMY_PACKAGE_ARCHS_TARGET in
> > layer.conf
> > which can be used to add these to the right places in the code.
> > 
> > Don't add the variables to task signatures as these only matter in
> > the
> > context of constructed images and not the recipes.
> > 
> > d-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> >  meta/classes-global/sstate.bbclass | 7 +++----
> >  meta/conf/layer.conf               | 3 +++
> >  meta/lib/oe/sstatesig.py           | 9 +++------
> >  3 files changed, 9 insertions(+), 10 deletions(-)
> > 
> > diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-
> > global/sstate.bbclass
> > index a7c3f5332a2..fe70a976869 100644
> > --- a/meta/classes-global/sstate.bbclass
> > +++ b/meta/classes-global/sstate.bbclass
> > @@ -86,14 +86,13 @@ SSTATE_ARCHS = " \
> >      ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} \
> >      ${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS} \
> >      ${SDK_ARCH}-${SDKPKGSUFFIX} \
> > -    buildtools-dummy-${SDKPKGSUFFIX} \
> > -    sdk-provides-dummy-target \
> > -    sdk-provides-dummy-${SDKPKGSUFFIX} \
> > +    ${DUMMY_PACKAGE_ARCHS_SDK} \
> > +    ${DUMMY_PACKAGE_ARCHS_TARGET} \
> >      allarch \
> >      ${SSTATE_ARCHS_TUNEPKG} \
> >      ${PACKAGE_EXTRA_ARCHS} \
> >      ${MACHINE_ARCH}"
> > -SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING"
> > +SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING
> > DUMMY_PACKAGE_ARCHS_SDK DUMMY_PACKAGE_ARCHS_TARGET"
> > 
> >  SSTATECREATEFUNCS += "sstate_hardcode_path"
> >  SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
> > diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> > index ba25ca30296..4794e660aed 100644
> > --- a/meta/conf/layer.conf
> > +++ b/meta/conf/layer.conf
> > @@ -133,6 +133,9 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
> >  # dependency in the recipe.
> >  SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
> > 
> > +DUMMY_PACKAGE_ARCHS_SDK = "buildtools-dummy-${SDKPKGSUFFIX} sdk-
> > provides-dummy-${SDKPKGSUFFIX}"
> > +DUMMY_PACKAGE_ARCHS_TARGET = "sdk-provides-dummy-target"
> 
> Wouldn't it be more appropriate to use += for these two?
> Otherwise one will have to use :append to add to them in other
> layers.

That depends on whether your layer is included after core or not. I'd
have thought including before core would be potentially problematic
anyway...

Cheers,

Richard


  reply	other threads:[~2026-03-16 11:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-14 10:27 [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings Richard Purdie
2026-03-14 10:45 ` Patchtest results for " patchtest
2026-03-16 11:21 ` [OE-core] " Peter Kjellerstedt
2026-03-16 11:28   ` Richard Purdie [this message]
2026-03-16 13:03     ` Peter Kjellerstedt
2026-03-17  8:22       ` Richard Purdie
2026-03-17 17:41         ` Peter Kjellerstedt
2026-03-17 20:39           ` Richard Purdie

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=3f73b46c12aff52292d488f48d11572c66991b70.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.kjellerstedt@axis.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox