[yocto] Variable locality too restricted.

[Richard Purdie]

On Thu, 2011-12-08 at 10:49 -0800, Darren Hart wrote:
> On 12/08/2011 06:31 AM, Bruce Ashfield wrote:
> > If you want to then modify the configuration slightly using either
> > in-tree or add on kernel
> > configuration fragments you can simply add a .cfg to the SCR_URI or set the
> > KERNEL_FEATURES variable, just like Darren did recently.
> > 
> >    KERNEL_FEATURES_append_fri2 += " cfg/smp.scc cfg/efi-ext.scc"
> 
> 
> This has the same original variable scope issue as before however. It
> would be nice to be able to do this:
> 
> $ bitbake core-image-minimal
> $ bitbake core-image-minimal-debug
> 
> The latter image would use the same machine, but it would build perf,
> add "debug" and other configurable options to "APPEND", and add a
> configurable set of KERNEL_FEATURES. We should also update the base
> kernel tools (non-Yocto) to use merge_config.sh so fragments can be used
> in those recipes as well.
> 
> The problem I've run into here in the past has been that I cannot
> specify things like PREFERRED_PROVIDER in the image recipe. So, for
> example, to build RT, the current documented approach is to first add a
> PREFERRED_PROVIDER line to either local.conf or bblayers to select
> linux-yocto-rt and then to build core-image-rt which merely adds some
> relevant packages. It would be much preferable to be able to specify
> just an image target and not have to change your configuration because
> the image is the intuitive distinguishing factor for people.

I'd like to give the bitbake perspective on this problem.

PREFERRED_PROVIDER in images doesn't really make sense to bitbake.
Imagine you have:

core-image-minimal setting PREFERRED_PROVIDER = "kernelA" and
core-image-minima-debug setting PREFERRED_PROVIDER = "kernelB". Both
would depend on "virtual/kernel". You then run:

"bitbake core-image-minimal core-image-minimal-debug"

What would you expect bitbake to do?

The kernel is special in that doesn't really stage output that is reused
by other parts of the system but we have to consider the general case
where output such as libraries would end up in a shared sysroot. Even
then, the kernel does generate packages which it places in a machine
specific feed and the names don't reflect the different inputs, there is
one kernel-image package for example and in the above case it would be a
race on which one built last.

Bitbake therefore takes PREFERRED_PROVIDER and VERSION decisions from
the core configuration (.conf / .inc / machine / distro / bitbake.conf /
base.bbclass). There is no easy solution to this problem, even recipe
specific sysroots would only get a part solution.

Having said that, if you enable sstate checksums on the stamp files, you
will get a system that is *much* more responsive to change. With that
enabled you could:

bitbake core-image-minimal
<realise you need debug enabled>
<edit some .conf which turns it on>
bitbake core-image-minimal
<have an image with debug enabled>

The reason is that with the checksums on, bitbake can tell exactly what
changed, what it needs to rebuild and it will then do so.

Cheers,

Richard