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

[Andy Gikling]

Ross,

Perfect thank you so much.  That makes total sense now.

I like the idea of just having two different recipes and then use IMAGE_INSTALL.  However, in the u-boot example I’m actually just using a bbappend to the u-boot recipe provided with our target SOM’s bsp.  Can I select different bbappend files in my image recipe with IMAGE_INSTALL?  I don’t think so but I’ll try though.

So what do I do in that case? Just make two of my own versions of the u-boot_2014.04.bb file, and give them different names?  For example “u-boot-faux_2014.04.bb” and “u-boot-faux-debug_2014.04.bb” ?  That should work but does that make sense to do?

Thanks again,

~Andy Gikling

From: Burton, Ross [mailto:ross.burton at intel.com]
Sent: Friday, April 08, 2016 9:44 AM
To: Andy Gikling
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] Prescribed way to make global variables in recipes?

On 8 April 2016 at 15:30, Andy Gikling <agikling at minnetronix.com<mailto:agikling at minnetronix.com>> wrote:
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?

You can't.  The basic reason being that images are built from packages, and the packages have already been built when the image is built.

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<http://faux-app_0.1.bb>” and “faux-app-debug_0.1.bb<http://faux-app-debug_0.1.bb>” called FAUX_RELEASE_MODE.  In faux-app_0.1.bb<http://faux-app_0.1.bb> this variable would be set to “release” and in faux-app-debug_0.1.bb<http://faux-app-debug_0.1.bb> it would be set to “debug.”

In your view, what would happen if you did "bitbake faux-app faux-app-debug"?

There are several ways to fix this that don't involve breaking how OE works.  Either have a rootfs-time postprocess command in the debug image recipe that manipulates the installed file system, or have two recipes for the thing that changes (in this case u-boot) where one includes the other and makes the changes required, and the image install the relevant package (u-boot vs u-boot-debug).

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