All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: [PATCH 1/5] kernel-yocto: allow in-tree defconfigs
Date: Tue, 24 Mar 2015 14:57:49 -0400	[thread overview]
Message-ID: <f3f09243e4101fb20f05cb9f996fd0c2c5dcdbbe.1427222980.git.bruce.ashfield@windriver.com> (raw)
In-Reply-To: <cover.1427222980.git.bruce.ashfield@windriver.com>

In a similar manner to the kernel itself, which does the following to
bring a defconfig into the configuration:

    defconfig: $(obj)/conf
    ifeq ($(KBUILD_DEFCONFIG),)
        $< --defconfig $(Kconfig)
    else
        @echo "*** Default configuration is based on '$(KBUILD_DEFCONFIG)'"
        $(Q)$< --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
    endif

We do the same with the linux-yocto configuration processing. If a
defconfig is specified via the KBUILD_DEFCONFIG variable, we copy it
from the source tree, into a common location and normalized "defconfig"
name, where the rest of the process will include and incorporate it
into the configuration process.

If the fetcher has already placed a defconfig in WORKDIR (from the
SRC_URI), we don't overwrite it, but instead warn the user that SRC_URI
defconfigs take precedence.

[YOCTO: #7474]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel-yocto.bbclass | 39 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 1e226a5722ac..14551a23f28c 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -56,6 +56,7 @@ def get_machine_branch(d, default):
     return default
 
 do_kernel_metadata() {
+	set +e
 	cd ${S}
 	export KMETA=${KMETA}
 
@@ -75,6 +76,41 @@ do_kernel_metadata() {
 		machine_srcrev="${SRCREV}"
 	fi
 
+	# In a similar manner to the kernel itself:
+	#
+	#   defconfig: $(obj)/conf
+	#   ifeq ($(KBUILD_DEFCONFIG),)
+	#	$< --defconfig $(Kconfig)
+	#   else
+	#	@echo "*** Default configuration is based on '$(KBUILD_DEFCONFIG)'"
+	#	$(Q)$< --defconfig=arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
+	#   endif
+	#
+	# If a defconfig is specified via the KBUILD_DEFCONFIG variable, we copy it
+	# from the source tree, into a common location and normalized "defconfig" name,
+	# where the rest of the process will include and incoroporate it into the build
+	#
+	# If the fetcher has already placed a defconfig in WORKDIR (from the SRC_URI),
+	# we don't overwrite it, but instead warn the user that SRC_URI defconfigs take
+	# precendence.
+	#
+	if [ -n "${KBUILD_DEFCONFIG}" ]; then
+		if [ -f "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" ]; then
+			if [ -f "${WORKDIR}/defconfig" ]; then
+				# If the two defconfigs are the same, leave the existing one in place
+				cmp "${WORKDIR}/defconfig" "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
+				if [ $? -ne 0 ]; then
+					bbnote "defconfig detected in WORKDIR. ${KBUILD_DEFCONFIG} skipped"
+				else
+					cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
+					sccs="${WORKDIR}/defconfig"
+				fi
+			fi
+		else
+			bbfatal "A KBUILD_DECONFIG '${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
+		fi
+	fi
+
 	# if we have a defined/set meta branch we should not be generating
 	# any meta data. The passed branch has what we need.
 	if [ -n "${KMETA}" ]; then
@@ -86,11 +122,10 @@ do_kernel_metadata() {
 		bbfatal "Could not create ${machine_branch}"
 	fi
 
-	sccs="${@" ".join(find_sccs(d))}"
+	sccs="$sccs ${@" ".join(find_sccs(d))}"
 	patches="${@" ".join(find_patches(d))}"
 	feat_dirs="${@" ".join(find_kernel_feature_dirs(d))}"
 
-	set +e
 	# add any explicitly referenced features onto the end of the feature
 	# list that is passed to the kernel build scripts.
 	if [ -n "${KERNEL_FEATURES}" ]; then
-- 
2.1.0



  reply	other threads:[~2015-03-24 18:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24 18:57 [PATCH 0/5] linux-yocto: consolidated pull request Bruce Ashfield
2015-03-24 18:57 ` Bruce Ashfield [this message]
2015-03-24 18:57 ` [PATCH 2/5] linux-yocto/3.19: configuration updates and stable import Bruce Ashfield
2015-03-24 18:57 ` [PATCH 3/5] linux-yocto/3.14: integrate korg stable and meta data changes Bruce Ashfield
2015-03-24 18:57 ` [PATCH 4/5] linux-yocto/3.19: fixes for Intel core warnings Bruce Ashfield
2015-04-13 23:11   ` Martin Jansa
2015-03-24 18:57 ` [PATCH 5/5] skeleton: clarify linux-yocto-custom workflow Bruce Ashfield
2015-03-25  9:26 ` [PATCH 0/5] linux-yocto: consolidated pull request Richard Purdie
2015-03-25 12:13   ` Bruce Ashfield
2015-03-25 13:26     ` Bruce Ashfield
2015-03-25 13:52       ` Richard Purdie

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=f3f09243e4101fb20f05cb9f996fd0c2c5dcdbbe.1427222980.git.bruce.ashfield@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 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.