On 02/02/2013 03:08 AM, Bruce Ashfield wrote: > > > > On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold > wrote: > > On 02/01/2013 06:18 AM, Bruce Ashfield wrote: > > > > > On Fri, Feb 1, 2013 at 4:00 AM, > >> > wrote: > > From: Chen Qi >> > > > Add config fragments to busybox. > > Both the implementation and the use case are similar to > yocto kernel's > configuration fragments. > > > I can fairly easily tweak the configuration parts of the > kern-tools to > handle this > use case as well. That would allow us to re-use the kernel's > merge_config.sh > script (with a minor dependency change) and save some > duplicated code. It > also gets you the advantage that you can consolidate > configuration fragments > outside of any build system, which isn't as critical here, but > something > that > is used quite a bit during kernel testing. > > Bruce, > > Where is the merge_config.sh script today? Would you propose > moving it to the scripts dir and have the busybox recipe call it? > > > It's part of the mainline kernel, hence why grabbing the guts out of > it reproducing > it here isn't the best idea, we'll have a need to keep them in sync. > In fact, I have > 2 or 3 pending patches for it in the kern-tools repository that I need > to get upstream > (as an example). > > I'd propose either creating a separate recipe for it (i.e. like > kconfig-frontends) or I could > keep it in kern-tools (badly named, but we can work on that ;) and > maintain / coordinate > changes to it. > > I just don't want to see the effort happen twice, we are busy enough! I thought about keeping the codes in sync but couldn't figure out a nice way. It would be great if you do so. Thanks in advance :) Best Regards, Chen Qi > > What would be your timing on making such a change, ie hold this > patch until your get it merge or merge this and then fix it when > you merge your changes? > > > I could feasibly get it done in the next few weeks, the changes aren't > bug, I just > have to avoid regressions on either side (kernel or busy box). > > That being said, the interface to the SRC_URI is the same for the two, > so if we are > ok with me arriving and removing the in-recipe support, I guess I > can't object too > much :) The only risk is that if anyone starts using this first > support immediately, > I do risk regressing their use case, where if it never goes in, that > won't happen. > > Cheers, > > Bruce > > > > Sau! > > To be clear, I'm not talking about the entire kern-tools here, > just the > config parts. > > Cheers, > > Bruce > > > [YOCTO #3379] > > Signed-off-by: Chen Qi > >> > > --- > meta/recipes-core/busybox/busybox.inc | 45 > +++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > > diff --git a/meta/recipes-core/busybox/busybox.inc > b/meta/recipes-core/busybox/busybox.inc > index 972e7d0..66044f8 100644 > --- a/meta/recipes-core/busybox/busybox.inc > +++ b/meta/recipes-core/busybox/busybox.inc > @@ -112,8 +112,53 @@ do_prepare_config () { > fi > } > > +# returns all the elements from the src uri that are .cfg > files > +def find_cfgs(d): > + sources=src_patches(d, True) > + sources_list=[] > + for s in sources: > + if s.endswith('.cfg'): > + sources_list.append(s) > + > + return sources_list > + > +# Merge config fragments > +# All config fragments for busybox should end with .cfg > +do_merge_config() { > + SED_CONFIG_EXP="s/^\(# > \)\{0,1\}\(CONFIG_[a-zA-Z0-9_]*\)[= > ].*/\2/p" > + MERGE_LIST="${@" ".join(find_cfgs(d))}" > + if [ -n "$MERGE_LIST" ]; then > + # Make a temp file, merge .config and > .cfg files > into it > + TMP_FILE=`mktemp .tmp.config.XXXXXXXX` > + cp .config $TMP_FILE > + for MERGE_FILE in $MERGE_LIST; do > + CFG_LIST=`sed -n "${SED_CONFIG_EXP}" > $MERGE_FILE` > + for CFG in $CFG_LIST ; do > + grep -q -w $CFG $TMP_FILE > + if [ $? -eq 0 ] ; then > + PREV_VAL=`grep -w $CFG > $TMP_FILE` > + NEW_VAL=`grep -w $CFG > $MERGE_FILE` > + if [ "x$PREV_VAL" != > "x$NEW_VAL" ] ; then > + echo Value of $CFG > is redefined by fragment $MERGE_FILE: > + echo Previous > value: $PREV_VAL > + echo New value: > $NEW_VAL > + echo > + fi > + sed -i "/$CFG[ > =]/d" $TMP_FILE > + fi > + done > + echo >> $TMP_FILE > + cat $MERGE_FILE >> $TMP_FILE > + done > + # Copy the temp file to .config, do some > cleanup > + cp $TMP_FILE .config > + rm $TMP_FILE > + fi > +} > + > do_configure () { > do_prepare_config > + do_merge_config > cml1_do_configure > } > > -- > 1.7.9.5 > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > > > > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness > await > thee at its end" > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end"