All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/5] kconfig-package: add support for config fragments
Date: Sat, 02 May 2015 12:37:04 +0200	[thread overview]
Message-ID: <5544A8D0.5080009@mind.be> (raw)
In-Reply-To: <1430231675-8613-1-git-send-email-bos@je-eigen-domein.nl>

On 28/04/15 16:34, Floris Bos wrote:
> Adds functionality to the kconfig infrastructure to merge additional
> configuration fragment files to the main configuration file of
> kconfig packages, using support/kconfig/merge_config.sh
> 
> Typical use-case is when you want your configuration to be
> kept in sync with an upstream (def)config file, but do require
> some minor local modifications.
> 
> Disables -update-config and -update-defconfig targets when
> fragment files are set.
> 
> Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>

[snip]

> +* +FOO_KCONFIG_FRAGMENT_FILES+: a space-separated list of configuration
> +  fragment files that are merged to the main configuration file.
> +  Fragment files are typically used when there is a desire to stay in sync
> +  with an upstream (def)config file, with some minor modifications.

 I should have noticed this in the first iteration, but why do we need an
additional config option for this? We could just rename _KCONFIG_FILE to
_KCONFIG_FILES and update the help texts to explain that the files may consist
of fragments.

> +
>  * +FOO_KCONFIG_OPTS+: extra options to pass when calling the kconfig
>    editors. This may need to include '$(FOO_MAKE_OPTS)', for example. By
>    default, empty.
> diff --git a/package/pkg-kconfig.mk b/package/pkg-kconfig.mk
> index 8361064..21fbfdb 100644
> --- a/package/pkg-kconfig.mk
> +++ b/package/pkg-kconfig.mk
> @@ -35,18 +35,20 @@ $(call inner-generic-package,$(1),$(2),$(3),$(4))
>  $(2)_KCONFIG_EDITORS ?= menuconfig
>  $(2)_KCONFIG_OPTS ?=
>  $(2)_KCONFIG_FIXUP_CMDS ?=
> +$(2)_KCONFIG_FRAGMENT_FILES ?=
>  
>  # The config file could be in-tree, so before depending on it the package should
>  # be extracted (and patched) first
>  $$($(2)_KCONFIG_FILE): | $(1)-patch

 The fragments could also be in-tree, in theory.

 Not that it matters in practice because it is only relevant for the .config
dependency.

>  
> -# The .config file is obtained by copying it from the specified source
> -# configuration file, after the package has been patched.
> +# The specified source configuration file and any additional configuration file
> +# fragments are merged together to .config, after the package has been patched.
>  # Since the file could be a defconfig file it needs to be expanded to a
>  # full .config first. We use 'make oldconfig' because this can be safely
>  # done even when the package does not support defconfigs.
> -$$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE)
> -	$$(INSTALL) -m 0644 $$($(2)_KCONFIG_FILE) $$($(2)_DIR)/.config
> +$$($(2)_DIR)/.config: $$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES)
> +	support/kconfig/merge_config.sh -m -O $$(@D) \
> +		$$($(2)_KCONFIG_FILE) $$($(2)_KCONFIG_FRAGMENT_FILES)
>  	@yes "" | $$($(2)_MAKE_ENV) $$(MAKE) -C $$($(2)_DIR) \
>  		$$($(2)_KCONFIG_OPTS) oldconfig
>  
> @@ -87,6 +89,8 @@ $(1)-savedefconfig: $$($(2)_DIR)/.stamp_kconfig_fixup_done
>  # Even though we could use 'cp --preserve-timestamps' here, the separate
>  # cp and 'touch --reference' is used for symmetry with $(1)-update-defconfig.
>  $(1)-update-config: $$($(2)_DIR)/.stamp_kconfig_fixup_done
> +	$$(if $$($(2)_KCONFIG_FRAGMENT_FILES), \

 So this could be
	$$(if $$(word 2,$$($(2)_KCONFIG_FILES)), \


 Regards,
 Arnout

> +		echo "Unable to perform $(1)-update-config when fragment files are set"; exit 1)
>  	cp -f $$($(2)_DIR)/.config $$($(2)_KCONFIG_FILE)
>  	touch --reference $$($(2)_DIR)/.config $$($(2)_KCONFIG_FILE)
>  
> @@ -95,6 +99,8 @@ $(1)-update-config: $$($(2)_DIR)/.stamp_kconfig_fixup_done
>  # $(1)-update-config, the reference for 'touch' is _not_ the file from which
>  # we copy.
>  $(1)-update-defconfig: $(1)-savedefconfig
> +	$$(if $$($(2)_KCONFIG_FRAGMENT_FILES), \
> +		echo "Unable to perform $(1)-update-defconfig when fragment files are set"; exit 1)
>  	cp -f $$($(2)_DIR)/defconfig $$($(2)_KCONFIG_FILE)
>  	touch --reference $$($(2)_DIR)/.config $$($(2)_KCONFIG_FILE)
>  
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  parent reply	other threads:[~2015-05-02 10:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 14:34 [Buildroot] [PATCH v2 1/5] kconfig-package: add support for config fragments Floris Bos
2015-04-28 14:34 ` [Buildroot] [PATCH v2 2/5] linux: add option to specify " Floris Bos
2015-05-02 10:39   ` Arnout Vandecappelle
2015-05-02 12:44   ` Arnout Vandecappelle
2015-05-06  4:16     ` Gergely Imreh
2015-04-28 14:34 ` [Buildroot] [PATCH v2 3/5] busybox: " Floris Bos
2015-05-02 12:47   ` Arnout Vandecappelle
2015-04-28 14:34 ` [Buildroot] [PATCH v2 4/5] uclibc: " Floris Bos
2015-05-02 12:55   ` Arnout Vandecappelle
2015-04-28 14:34 ` [Buildroot] [PATCH v2 5/5] barebox: " Floris Bos
2015-05-02 12:55   ` Arnout Vandecappelle
2015-05-02 10:37 ` Arnout Vandecappelle [this message]
2015-05-02 11:30   ` [Buildroot] [PATCH v2 1/5] kconfig-package: add support for " Floris Bos
2015-05-02 12:43 ` Arnout Vandecappelle
2015-05-06  4:14   ` Gergely Imreh
2015-05-21 21:52 ` 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=5544A8D0.5080009@mind.be \
    --to=arnout@mind.be \
    --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.