All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3/3] New <pkg>-update-last-config-fragment target in pkg-kconfig.mk
Date: Tue, 31 Jul 2018 17:49:48 +0200	[thread overview]
Message-ID: <20180731154948.GB8537@scaer> (raw)
In-Reply-To: <20180730234643.34315d11@windsurf>

Thomas, Marcel, All,

On 2018-07-30 23:46 +0200, Thomas Petazzoni spake thusly:
> 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?

I would advocate that we do a generic solution like Thomas suggests,
because it is generic enough that it would help solve more use-cases
than this patch does.

So, I side with Thomas here.

I would just suggest that we do not add any new rule, but trying to
update the defconfig when there are fragments would fail as it currently
does, but also would display the delta if there is one. I.e.:

    $ make linux-menuconfig
    [change stuff]
    $ make linux-update-defconfig
    Unable to perform linux-update-defconfig when fragment files are set
    Configuration changes that you want to propagate to one of the fragments:
    -CONFIG_FOO=y
    +# CONFIG_BAR is unset
    linux/linux.mk:511: recipe for target 'linux-update-defconfig' failed
    make[1]: *** [linux-update-defconfig] Error 1

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  parent reply	other threads:[~2018-07-31 15:49 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
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     ` Yann E. MORIN [this message]
2018-08-14 14:27       ` [Buildroot] " 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=20180731154948.GB8537@scaer \
    --to=yann.morin.1998@free.fr \
    --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 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.