[yocto] creating global variables in a recipes
William Mills
wmills at ti.com
Wed Feb 1 08:50:16 PST 2012
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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
More information about the yocto
mailing list