[OE-core] Kernel: Builds use old version of defconfig
Andre McCurdy
armccurdy at gmail.com
Tue Nov 29 17:49:21 UTC 2016
On Mon, Nov 28, 2016 at 11:58 PM, Mike Looijmans
<mike.looijmans at topic.nl> wrote:
>
> The current system assumes that the kernel recipe creates a
> do_configure_prepend to do the mangling, which is rather counterintuitive,
> one would expect to "append" extra actions.
For reference, I've implemented support for merging of config
fragments in kernel.bbclass based kernel recipes just by over-riding
KERNEL_CONFIG_COMMAND. No do_configure_prepend required.
The basic version is:
KERNEL_CONFIG_COMMAND = " \
cd ${S} ; \
${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config `ls
${WORKDIR}/*.cfg 2>/dev/null` ; \
cd ${B} \
"
The debug version, with lots of error checking etc to verify that
calling merge_config.sh with no config fragments is equivalent to the
default KERNEL_CONFIG_COMMAND (which calls "make oldnoconfig" with a
fallback to "yes '' | make oldconfig" for _very_ old kernels) is:
KERNEL_CONFIG_COMMAND = " \
set -x ; \
cp .config .config_original ; \
cd ${S} ; \
oe_runmake_call O=${B} oldnoconfig ; \
mv ${B}/.config ${B}/.config_oldnoconfig ; \
cp ${B}/.config_original ${B}/.config ; \
${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config ; \
mv ${B}/.config ${B}/.config_merged_no_fragments ; \
cp ${B}/.config_original ${B}/.config ; \
${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config `ls
${WORKDIR}/*.cfg 2>/dev/null` ; \
cp ${B}/.config ${B}/.config_merged_with_fragments ; \
cd ${B} ; \
diff -u .config_oldnoconfig .config_merged_no_fragments ; \
diff -u .config_oldnoconfig .config_merged_with_fragments || true \
"
> A structured approach would be to split the do_configure into two parts that
> should run in sequence, and then kernel recipes can inject their actions by
> appending to them as they see fit. The first task would create the .config
> file by (forcibly) copying any defconfig or starting point. The second task
> would call the kernel's make script to futher process it.
>
> But this too would break existing recipes.
>
More information about the Openembedded-core
mailing list