Openembedded Core Discussions

* Re: Kernel: Builds use old version of defconfig
From: Andre McCurdy @ 2016-11-29 17:49 UTC (permalink / raw)
  To: Mike Looijmans; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <de64dc20-cff3-5f25-7e66-55887e641e3e@topic.nl>

On Mon, Nov 28, 2016 at 11:58 PM, Mike Looijmans
<mike.looijmans@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.
>

^ permalink raw reply