From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: antonin.godard@bootlin.com, bitbake-devel@lists.openembedded.org
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [bitbake-devel] [PATCH RFC] parse/ast: add support for additive built-in fragments
Date: Tue, 01 Sep 2026 13:15:30 +0100 [thread overview]
Message-ID: <afffba8970ad228db773766f7f6c894cbb021279.camel@linuxfoundation.org> (raw)
In-Reply-To: <20260901-appending-fragments-v1-1-2e359cf751ce@bootlin.com>
On Tue, 2026-09-01 at 09:52 +0200, Antonin Godard via lists.openembedded.org wrote:
> Add support for the following syntax specified in a fragment list
> definition:
>
> fragmentname:VARIABLE:add
>
> Setting this fragment appends to VARIABLE instead of setting its value.
> This does not break pre-existing fragments which still set a variable's
> value entirely.
>
> For example, in OE-Core consider the following definition:
>
> OE_FRAGMENTS_BUILTIN = "class:INHERIT:add"
>
> Then one could specify the following:
>
> OE_FRAGMENTS = "class/buildstats class/rm_work"
>
> Which would result in appending " buildstats rm_work" to the INHERIT
> variable.
>
> This would also allow bitbake-setup configurations to come with a list
> of pre-enabled classes, for example.
>
> Note: The "add" suffix was chosen in the definition to avoid confusion
> with the existing "append" usage in Bitbake.
>
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
> Note: The bitbake-config-build OE-Core utility would require adaptations
> as it currently removes any pre-existing built-in fragment with the
> same suffix. I can also send the associated OE-Core patches.
>
> Note 2: We could also have these fragments specified as:
>
> OE_FRAGMENTS = "class/add/buildstats class/add/retain"
>
> To avoid confusing them with original built-in fragments. While I
> agree it disambiguates them from original built-ins, I also think from a
> user point of view, being able to set:
>
> OE_FRAGMENTS = "machine/qemuarm distro/poky class/buildstats class/retain"
>
> feels a bit more natural. Discussion is open :)
It is definitely an interesting one and the syntax isn't too bad.. Are
there uses beyond class inherit though?
machine/distro were added as they are clear variables in common use
which avoided tons of boilerplate in layer definitions. Do we have
similar needs here or are these inherits better captured in config
fragments?
Cheers,
Richard
next prev parent reply other threads:[~2026-09-01 12:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 7:52 [PATCH RFC] parse/ast: add support for additive built-in fragments Antonin Godard
2026-09-01 12:15 ` Richard Purdie [this message]
2026-09-01 18:28 ` [bitbake-devel] " Alexander Kanavin
2026-09-01 19:22 ` Richard Purdie
2026-09-02 7:56 ` Antonin Godard
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=afffba8970ad228db773766f7f6c894cbb021279.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=antonin.godard@bootlin.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=thomas.petazzoni@bootlin.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 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.