Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Bur <cyrilbur@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] Makefile: Support merged defconfigs
Date: Wed, 11 May 2016 14:34:17 +1000	[thread overview]
Message-ID: <20160511143417.0dae9edb@camb691> (raw)
In-Reply-To: <90639972664ebd51802b3c2b94b8c01e235bd956.1462771329.git.sam.bobroff@au1.ibm.com>

On Mon,  9 May 2016 15:22:32 +1000
Sam Bobroff <sam.bobroff@au1.ibm.com> wrote:

> Within the Linux kernel, and several other packages, it's currently
> possible to maintain defconfigs as diffs (fragments) against other
> configs but this is not possible with buildroot itself.
> 
> This patch adds the capability, although using a slightly different
> implementation. Files may be added in the normal config directories
> ($TOPDIR/configs or $BR2_EXTERNAL/configs) with the format
> "xxx_defconfig.merge" that contain, one per line, the files to be
> passed to merge_config.sh to create the matching xxx_defconfig file
> (the first line should contain the base config followed by the
> fragments).  The generated defconfig file is then handled as it would
> normally be.
> 
> Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
> ---
> For a discussion about this from the OP build project, see
> https://github.com/open-power/op-build/issues/457
> 

Hi Sam,

> A couple of things about the implementation:
> 
> * merge_config.sh will only output to a file called ".config" so I've set it up
>   to output directly to $TOPDIR/.config, since that's about to be overwritten
>   anyway, but I don't feel this is particularly nice.
> * It seems strange to pass --defconfig=.config when running conf but I couldn't
>   quickly tell if there was something better to do. Using --oldconfig would
>   pick up .config by default but I don't know if it would then process the file
>   correctly so I went with what seemed safe.

Looks like what you've done will work. I've come to the same conclusion as you
that --oldconfig might actually be a better fit, and by extension
--olddefconfig may be even better moving forward as the fragments age and new
symbols get added.

Then it occurred to me I've had this question before and I had to go look what I
did for linux in arch/powerpc/Makefile and turns out, olddefconfig.

> * I realise that there are now four very similar rules that handle defconfigs.
>   I could look at factoring them but it didn't seem worth the effort and
>   complexity at this point.
> 

I have no doubt there may be a refactored solution in there somewhere but I
don't believe it will be as easy to follow as what currently exists. Currently
it is easy to understand why there are four, what they are trying to achieve,
I'd bet that with any refactoring that clarity will be dulled.

>  Makefile | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index 71735b5..eb80152 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -845,6 +845,16 @@ defconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>  	@$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$(BR2_EXTERNAL)/configs/$@ \
>  		$< --defconfig=$(BR2_EXTERNAL)/configs/$@ $(CONFIG_CONFIG_IN)
>  
> +%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(TOPDIR)/configs/%_defconfig.merge outputmakefile
> +	cd $(TOPDIR)/configs && xargs -a $@.merge -x -P 1 $(TOPDIR)/support/kconfig/merge_config.sh -m -O $(TOPDIR)
> +	$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$(TOPDIR)/.config \
> +		$< --defconfig=$(TOPDIR)/.config $(CONFIG_CONFIG_IN)
> +
> +%_defconfig: $(BUILD_DIR)/buildroot-config/conf $(BR2_EXTERNAL)/configs/%_defconfig.merge outputmakefile
> +	cd $(BR2_EXTERNAL)/configs && xargs -a $@.merge -x -P 1 $(TOPDIR)/support/kconfig/merge_config.sh -m -O $(TOPDIR)
> +	$(COMMON_CONFIG_ENV) BR2_DEFCONFIG=$(TOPDIR)/.config \
> +		$< --defconfig=$(TOPDIR)/.config $(CONFIG_CONFIG_IN)
> +
>  savedefconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>  	@$(COMMON_CONFIG_ENV) $< \
>  		--savedefconfig=$(if $(DEFCONFIG),$(DEFCONFIG),$(CONFIG_DIR)/defconfig) \

  parent reply	other threads:[~2016-05-11  4:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09  5:22 [Buildroot] [PATCH 1/1] Makefile: Support merged defconfigs Sam Bobroff
2016-05-10  1:04 ` Samuel Mendoza-Jonas
2016-05-11  4:34 ` Cyril Bur [this message]
2016-05-12 14:02 ` Thomas Petazzoni
2016-05-12 21:58   ` Arnout Vandecappelle
2016-05-13 12:59     ` 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=20160511143417.0dae9edb@camb691 \
    --to=cyrilbur@gmail.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