Re: creating global variables in a recipes

[William Mills <wmills@ti.com>]

On 02/01/2012 10:49 AM, Joshua Immanuel wrote:
> Hello all,
>
> On Wed, 2012-02-01 at 12:07 +0530, Joshua Immanuel wrote:
>>> At present in my custom image recipe I've added the following
>>> lines
>>>
>>>          SOME_VARIABLE = "Blah"
>>>          do_bootimg[depends] += "base-files:do_install"
>>>
>>> But the contents of ${SOME_VARIABLE} is not available in the
>>> 'base-files' recipe. Even
>>>
>>>          export SOME_VARIABLE = "Blah"
>>>
>>> doesn't solve the problem.
>>
>>          $ bitbake custom-image -c devshell
>>
>> In the above devshell I can find the contents of ${SOME_VARIABLE}
>> available but the content of it is empty in 'base-files' recipe.
>
> In other words, I need to define global variables in a package which can
> be used across multiple packages. At present the only option I have is
> to export the variable in build/conf/local.conf. IMHO, this doesn't feel
> like a proper solution (as the variable is my layer specific). Moreover,
> I can't change the value of it in one package to be used in other
> package(s).
>
> Is there any other way to do this? Please guide me.
>

I am not sure I can give you a better option that local.conf but I can 
explain why what your doing does not work.

It may feel from your usage that the image recipe is the ancestor of all 
the recipes but this is really not true.  The settings in a image recipe 
effect the assembly of that image and not the packages that they depend 
on.  An image could be assembled from packages that were built long ago 
or inherited via shared state.

settings in local,conf on the other hand affect all recipes.  If you add 
something there it will be seen by all recipes.  Unfortunately this 
means that all recipes are dependent on the settings and everything will 
need to be rebuilt in case the new setting effects them.  I believe this 
also means you will not be able to used share state with someone with a 
different setting of (or unset) SOME_VARIABLE.  (Well you can but you 
will both be rebuild everything.)

Alternatives to the whole approach are to make alternative packages for 
the various cases (busybox-minimal vs busybox-full) or use an image task 
to create an asset in the file system that then makes a difference at 
run time.

> Regards
> Joshua
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto