From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: openembedded-core@lists.openembedded.org,
Alexander Kanavin <alex@linutronix.de>
Subject: Re: [OE-core] [PATCH v3 3/3] bitbake-config-build: add a plugin for config fragments
Date: Mon, 16 Dec 2024 16:58:44 +0000 [thread overview]
Message-ID: <1647f808543a0851f5a1a17e293f1a68970f7c0e.camel@linuxfoundation.org> (raw)
In-Reply-To: <CANNYZj-Ox6t8yV7Bh2NePmseYCW843Z5ozq50y2Tyoa=GeDPyg@mail.gmail.com>
On Wed, 2024-12-11 at 12:24 +0100, Alexander Kanavin wrote:
> On Tue, 10 Dec 2024 at 16:27, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>
> > > If we start going down this path, we might as well write an
> > > interactive curses UI, and keep the command line output 'flat'
> > > like it
> > > is now. I'm also not sure what is the best approach, we'd need to
> > > take
> > > fragments into practical use and accumulate a sizable amount of
> > > them
> > > perhaps. Such things can be easily tweaked from experience.
> >
> > Having experimented with curses UIs, they're a pain and don't
> > really do
> > what you hope/think they would.
>
> We might be thinking of different things: my suggestion is that
> interactive 'kernel menuconfig' type UI is worth exploring for
> fragments (or bitbake-setup, for that matter).
We were talking about different things. I agree, I think something
kconfig like for some of this would be much appreciated by some users.
Cheers,
Richard
next prev parent reply other threads:[~2024-12-16 16:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 16:26 [PATCH v3 1/3] patchtest: use HEAD commit as base for the selftest and not master Alexander Kanavin
2024-11-18 16:26 ` [PATCH v3 2/3] bitbake.conf: add an addfragments directive for oe-core and dependent layers Alexander Kanavin
2024-11-18 16:26 ` [PATCH v3 3/3] bitbake-config-build: add a plugin for config fragments Alexander Kanavin
2024-11-18 16:32 ` Patchtest results for " patchtest
2024-12-09 16:33 ` [OE-core] " Richard Purdie
2024-12-10 12:22 ` Alexander Kanavin
2024-12-09 17:00 ` Richard Purdie
2024-12-10 13:05 ` Alexander Kanavin
2024-12-10 15:27 ` Richard Purdie
2024-12-11 11:24 ` Alexander Kanavin
2024-12-16 16:58 ` Richard Purdie [this message]
2024-12-20 17:39 ` Joshua Watt
2024-12-25 15:29 ` Alexander Kanavin
2024-12-25 15:33 ` Joshua Watt
2024-12-27 18:12 ` Joshua Watt
2024-12-27 18:44 ` Alexander Kanavin
2024-12-27 19:47 ` Joshua Watt
2024-11-18 16:33 ` [OE-core] [PATCH v3 1/3] patchtest: use HEAD commit as base for the selftest and not master Trevor Gamblin
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=1647f808543a0851f5a1a17e293f1a68970f7c0e.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alex.kanavin@gmail.com \
--cc=alex@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox