RFC: Rapid iterative development

RFC: Rapid iterative development

[Darren Hart]

While working on a single package, I need to be able to tweak a variable 
in the new recipe, change the MACHINE in local.conf, etc. I'd like to be 
able to rapidly test my changes, but some of these changes trigger a 
long list of dependencies for various commands. While working on a new 
linux kernel recipe, I found it rebuilding a number of things that were 
either -native (can I force it to use the system version rather than 
building one) or seemed unrelated to the process at hand.

Are there some best practices for iterative recipe development that 
speed things along?

Thanks,

-- 
Darren Hart
Yocto Linux Kernel

Re: RFC: Rapid iterative development

[Tian, Kevin]

>From: Darren Hart
>Sent: Saturday, November 20, 2010 7:14 AM
>
>While working on a single package, I need to be able to tweak a variable
>in the new recipe, change the MACHINE in local.conf, etc. I'd like to be
>able to rapidly test my changes, but some of these changes trigger a
>long list of dependencies for various commands. While working on a new
>linux kernel recipe, I found it rebuilding a number of things that were
>either -native (can I force it to use the system version rather than
>building one) or seemed unrelated to the process at hand.

That's interesting. Did you build from scratch or incrementally? Ideally only
recipes being changed will be rebuilt in incremental way.

>
>Are there some best practices for iterative recipe development that
>speed things along?
>

"bitbake -k" is one method if you're sure the dependency doesn't change.
But if you change MACHINE, I think a whole rebuild except -native will
be required as it's the fundamental bit for target recipes.

Thanks
Kevin

Re: RFC: Rapid iterative development

[Darren Hart]

On 11/19/2010 03:42 PM, Tian, Kevin wrote:
>> From: Darren Hart
>> Sent: Saturday, November 20, 2010 7:14 AM
>>
>> While working on a single package, I need to be able to tweak a variable
>> in the new recipe, change the MACHINE in local.conf, etc. I'd like to be
>> able to rapidly test my changes, but some of these changes trigger a
>> long list of dependencies for various commands. While working on a new
>> linux kernel recipe, I found it rebuilding a number of things that were
>> either -native (can I force it to use the system version rather than
>> building one) or seemed unrelated to the process at hand.
>
> That's interesting. Did you build from scratch or incrementally? Ideally only
> recipes being changed will be rebuilt in incremental way.

By changing machine type (and therefor architecture) I probably trigger 
at least all the non -native builds. These were clean builds. I'd just 
like to eliminate as much of that as possible when testing things like:

$ bitbake linux-linaro -c fetch

and

$ bitbake linux-linaro -c configure

>
>>
>> Are there some best practices for iterative recipe development that
>> speed things along?
>>
>
> "bitbake -k" is one method if you're sure the dependency doesn't change.
> But if you change MACHINE, I think a whole rebuild except -native will
> be required as it's the fundamental bit for target recipes.

OK, time to get this off the laptop and onto something with some serious 
storage then I guess.

-- 
Darren Hart
Yocto Linux Kernel

Re: RFC: Rapid iterative development

[Joshua Lock]

On Fri, 2010-11-19 at 15:14 -0800, Darren Hart wrote:
> While working on a single package, I need to be able to tweak a variable 
> in the new recipe, change the MACHINE in local.conf, etc. I'd like to be 
> able to rapidly test my changes, but some of these changes trigger a 
> long list of dependencies for various commands. While working on a new 
> linux kernel recipe, I found it rebuilding a number of things that were 
> either -native (can I force it to use the system version rather than 
> building one) or seemed unrelated to the process at hand.

You can use ASSUME_PROVIDED to use system versions of native tools,
though it's generally not recommended. git grep for the term to find
some examples.

As to building things which seem unrelated, this is possibly because you
have BB_NUMBER_THREADS set high and bitbake is just using the
opportunity to finish some uncompleted tasks - oft a desirable
behaviour.

You could always try BB_NUMBER_THREADS=1 bitbake whatever-package and
see if that behaves more like you expect?


> 
> Are there some best practices for iterative recipe development that 
> speed things along?
> 
> Thanks,
> 

-- 
Joshua Lock
        Intel Open Source Technology Centre