From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/3] New <pkg>-update-last-config-fragment target in pkg-kconfig.mk
Date: Mon, 30 Jul 2018 23:46:43 +0200 [thread overview]
Message-ID: <20180730234643.34315d11@windsurf> (raw)
In-Reply-To: <20180730155153.24091-4-m.patzlaff@pilz.de>
Hello Marcel,
On Mon, 30 Jul 2018 17:51:53 +0200, Marcel Patzlaff wrote:
> This patch adds the new target above which implements the update routine as
> detailled in the head of this patch series.
>
> Signed-off-by: Marcel Patzlaff <m.patzlaff@pilz.de>
Thanks for working on this complex topic, as Arnout said.
On my side, I find the semantic of "let's update the _last_ fragment"
to be a bit weird and complex to understand. Why the last one, and not
any other ?
I'm not sure it's possible to have something that updates fragments
with a sensible semantic.
However, what would be useful would be a way to dump the difference
between the current configuration, and what the combination of the
defconfig+fragments provide.
I.e, you start Buildroot with omap2plus_defconfig + some specific
fragments as the kernel configuration.
You run "make linux-show-config-diff", which returns empty.
Then you tweak the configuration with "make linux-menuconfig", and run
"make linux-show-config-diff", which shows you the lines that you need
to put in one of your fragments to preserve the configuration tweaks
you have done.
Of course, the name "linux-show-config-diff" is just made up here, and
some more thought is needed to find a good name. But overall, I believe
the semantic would be much clearer, and doesn't make any assumption on
whether we have one or several fragments, and whether the last fragment
or any other fragment needs to be updated.
What do you think about this? Would this also fill your needs?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-07-30 21:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 15:51 [Buildroot] [PATCH 0/3] Buildroot: Target to update config fragments in kconfig based packages Marcel Patzlaff
2018-07-30 15:51 ` [Buildroot] [PATCH 1/3] Support script for defconfig comparison Marcel Patzlaff
2018-07-30 15:51 ` [Buildroot] [PATCH 2/3] Refactoring of pkg-kconfig.mk to increase re-usability Marcel Patzlaff
2018-07-30 15:51 ` [Buildroot] [PATCH 3/3] New <pkg>-update-last-config-fragment target in pkg-kconfig.mk Marcel Patzlaff
2018-07-30 21:46 ` Thomas Petazzoni [this message]
2018-07-31 7:44 ` [Buildroot] Antwort: " Marcel Patzlaff
2018-07-31 7:53 ` [Buildroot] " Thomas Petazzoni
2018-07-31 8:43 ` [Buildroot] Antwort: " Marcel Patzlaff
2018-07-31 15:49 ` [Buildroot] " Yann E. MORIN
2018-08-14 14:27 ` Thomas Petazzoni
2018-08-14 15:29 ` Yann E. MORIN
2018-08-14 23:20 ` Arnout Vandecappelle
2018-08-15 12:04 ` Thomas Petazzoni
2018-08-15 16:16 ` Yann E. MORIN
2018-08-15 17:35 ` Thomas Petazzoni
2018-08-15 20:29 ` Yann E. MORIN
2018-08-15 22:15 ` Thomas Petazzoni
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=20180730234643.34315d11@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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