[poky] How to build a kernel using menuconfig

[Gary Thomas]

On 2011-09-28 07:15, Richard Purdie wrote:
> On Wed, 2011-09-28 at 05:33 -0600, Gary Thomas wrote:
>> On 2011-09-27 21:45, Darren Hart wrote:
>>>
>>>
>>> On 09/26/2011 06:45 AM, Gary Thomas wrote:
>>>> I'm working with a recent Poky checkout:
>>>>      meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
>>>>
>>>> I used to be able to do this:
>>>>      % bitbake<some-image>
>>>> This step builds everything, including the kernel
>>>>      % bitbake virtual/kernel -c menuconfig
>>>> Adjust some settings
>>>>      % bitbake virtual/kernel -c compile -f
>>>>      % bitbake virtual/kernel
>>>> Rebuild my image with the new kernel included
>>>>      % bitbake<some-image>
>>>>
>>>> In the past, this would let me adjust some kernel settings, e.g. add a new
>>>> module, then rebuild it and later add this to an image.  Sadly, when I run
>>>> through these steps with the current master, the new kernel gets compiled
>>>> (because I used -f), but not packaged.
>>>>
>>>> The only thing I've done differently, save updating master, is my build
>>>> today includes
>>>>      INHERIT += "rm_work"
>>>>
>>>> Am I missing something?
>>>>
>>>> How can I build the kernel and make these in-tree adjustments like I used to?
>>>> I do this to figure out what kernel settings to set/save for my final packaging.
>>>
>>>
>>> Yeah, this is standard kernel devel workflow. I typically use the kernel
>>> recipe name directly, but otherwise my process is the same. What happens
>>> now when you run "bitbake virtual/kernel" after the compile -f ?
>>>
>>
>> As indicated above, nothing.  If I remove rm_work from my configuration
>> and then rebuild the kernel, it works as expected.
>
> It sounds like there is a bad interaction between rm_work and this set
> of steps. I can kind of see why, rm_work promotes the stamp files to
> setscene ones (so the same as if a sstate build was made). Nothing in
> the above steps would actually remove the setscene stamps so bitbake
> sees them and assumes everything is still valid.
>
> If you did a bitbake -c package -f virtual/kernel then I suspect it
> would actually sort itself out. Off the top of my head I can't see a way
> to fix this in any straightforward way :/.

My inclination is to just not allow rm_work for kernel recipes.  Perhaps
it's possible to filter out rm_work for this recipe like this?
   INHERIT := "${@oe_filter_out('rm_work', '${INHERIT}', d)}"
Note: I've not tried it, just a thought.

Thanks for your time

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------