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

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

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

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