On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold <sgw@linux.intel.com> wrote:

On 02/01/2013 06:18 AM, Bruce Ashfield wrote:

On Fri, Feb 1, 2013 at 4:00 AM, <Qi.Chen@windriver.com

<mailto:Qi.Chen@windriver.com>> wrote:

    From: Chen Qi <Qi.Chen@windriver.com <mailto:Qi.Chen@windriver.com>>

    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!

 

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 <Qi.Chen@windriver.com

    <mailto:Qi.Chen@windriver.com>>

    ---
      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

    <mailto: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"