Dear Yocto,

First of all, I love this project.  Thanks for all your hard work.

Question:  What is the prescribed way to allow image recipes to make global 
configuration variables that other recipes can use?

After extensive research and educating myself on how bitbake works, it seems 
that what I'm asking for is technically not possible.  This issue is discussed 
previously without a clear conclusion in the mailing list:

https://lists.yoctoproject.org/pipermail/yocto/2012-February/004552.html

Another work around is to setup a BB_ENV_EXTRAWHITE variable as described here:

http://stackoverflow.com/questions/17366984/is-it-possible-to-pass-in-command-line-variables-to-a-bitbake-build

However, this doesn't seem like the right approach either.

If there's no way to make global variables in an image recipe it seems one of 
two things are true:  Either bitbake lacks this powerful feature for some 
reason or there's some other "prescribed" way to accomplish what I need and I 
just don't know what that is.  I suspect the latter is true.

Let me give a simple example of why I need this feature.  We are deploying an 
application with Yocto called "faux-app."  Once this product is live, I would 
like to use our continuous integration build mechanism to build images for 
faux-app that contain the latest version of the user space application code.

We have a meta-faux-app layer with a hand full of recipes that are gracefully 
customizing our image.  One of the recipes is an "image recipe" that pulls in 
core-image and builds the output deploy binaries called faux-app_0.1.bb.

Another recipe is essentially a bbappend that is in charge of applying a patch 
to u-boot.  This patch configures u-boot to behave in a "debug" fashion vs a 
"release" fashion (ie, defaulting to network boot for debug and sdcard boot for 
release).

Ideally, for CI purposes we would like to allow our CI server to simply call 
"bitbake faux-app" to make a release build and then "bitbake faux-app-debug" to 
make a debug build.  The thought process is I could have a variable defined in 
both "faux-app_0.1.bb" and "faux-app-debug_0.1.bb" called FAUX_RELEASE_MODE.  
In faux-app_0.1.bb this variable would be set to "release" and in 
faux-app-debug_0.1.bb it would be set to "debug."

Then, in the "u-boot_2014.04.bbappend" file found in our layer, we could append 
the correct patch to the SRC_URI variable using inline python logic for example:

SRC_URI += "${@base_contains('FAUX_RELEASE_MODE', 'release', 
'file://u-boot-mode-release.patch', ' file://u-boot-mode-debug.patch ', d)}"

So in this way I have my image recipe setting a value that tells other recipes 
how to behave.  This seems like a perfectly reasonable use case so I'm at a 
loss as to why bitbake doesn't support this (I understand the environment 
variables is "scrubbed" between recipes - it makes sense).  Is there another 
mechanism I'm not aware of?  Can someone give me an example of a different way 
to accomplish my use case described above?

Any guidance would be much appreciated!  Thanks,

~Andy Gikling


-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to