Re: [PATCH 1/1] busybox: add config fragments

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote:
>         On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
>         > 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:
>         >                 <mailto:Qi.Chen@windriver.com>> 
>         >                     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
>
>         Hi Bruce,
>
>         I just tried to reuse the kernel's merge_config.sh script, and
>         it turned out well.
>         The patch is in attachment.
>
>         Is it enough for now?
>
> Yep, this is enough for now. It re-uses the significant part of the
> infrastructure, which
> is the important part. Once it is in tree, I can refine the dependency
> and some other
> minor modifications.
>
> Feel free to add my Signed-off-by: to the patch as well.

This patch triggers a failure on the autobuilder:

http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/246/steps/shell_59/logs/stdio

(its reproducible, this is the second one now)

I suspect there is a missing DEPENDS += "kern-tools-native". 

You'd be able to reproduce this with a:

bitbake busybox kern-tools-native; bitbake busybox kern-tools-native -c clean; bitbake busybox

Cheers,

Richard