On Thu, Oct 16, 2014 at 10:21 PM, [email protected] <[email protected]> wrote: > Which part are you referencing here ? The LOCALVERSION changes ? > [Zongchun] I have separated the codes from this patch. these codes can also > add git revision to local version. Please refer to the following: > +kernel_conf_variable() { > + if test "$2" = "n" > + then > + echo "# CONFIG_$1 is not set" >> ${B}/.config > + else > + echo "CONFIG_$1=$2" >> ${B}/.config > + fi > +} > + > +do_configure_prepend() { > + kernel_conf_variable LOCALVERSION "\"${LOCALVERSION}\"" > + kernel_conf_variable LOCALVERSION_AUTO y > + > + if [ "${SCMVERSION}" = "y" ]; then > + # Add GIT revision to the local version > + cd source > + head=`git rev-parse --verify --short HEAD 2> /dev/null` > + cd - > + printf "%s%s" +g $head > ${S}/.scmversion > + fi > +} > > May I know your comments? Thanks.
Setting and manipulating raw CONFIG variables from within recipes is something that we've been trying to avoid via the configuration fragments. Getting the localversion right makes sense, but not at the expense of spreading configuration changes into a wider set of inputs (recipes, variables, fragments, python routines, etc). We already have a hard time managing configuration consistently and if CONFIG* variables need to be hunted and found, along with fragments and other custom routines .. then the entire system becomes harder to maintain (in particular when delivered BSPs are layered and modified). I'm definitely interested in solving configuration gaps, hopefully without needing to introduce more ways to configure the kernel. There are some existing bugzilla entries on this, and the priority is being bumped for Yocto 1.8. Cheers, Bruce -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
