[yocto] Prescribed way to make global variables in recipes?

[Andy Gikling]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160408/a524daae/attachment.html>