Re: Adding ALSA to the Yocto SDK

[Patrick Turley <PatrickTurley@gamestop.com>]

On Jan 21, 2013, at 5:16 PM, Patrick Turley <PatrickTurley@gamestop.com> wrote:

> On Jan 21, 2013, at 4:35 PM, "Zhang, Jessica" <jessica.zhang@intel.com> wrote:
> 
>> Hi Patrick,
>> 
>> Since you're able to add the dev packages to images, just do bitbake yourimagewithALSA -c populate_sdk, that should generate a SDK contains ALSA.  By default, meta-toolchain-sdk is predefined unless you use "-c populate_sdk" to enforce the SDK sysroot to match your rootfs.
> 
> 
> All the clues rolling in are starting to knit together.
> 
> At first, I regarded the "populate_sdk" task as a hack, since it seemed to be expressing something that was naturally a "target" -- not a "task."
> 
> Now I see that it is a way to connect an image to a corresponding SDK. That makes a *lot* more sense.

One of my colleagues did some research on this and I believe we've found the best way for *us* to do this.

We tried using a single image recipe. We tried both bitbake'ing this recipe directly *and* using the "populate_sdk" task with it. This gave us the SDK we needed, but it resulted in development header files appearing in the target root file system.

Like core-image-sato and core-image-sato-sdk, we'll have have two images:

1) A target image recipe.
We will bitbake this recipe directly to produce the target image. We will *never* use the "populate_sdk" task with this recipe.

2) An SDK image recipe.
This recipe "require's" the target image recipe and adds various development packages to it. We will *never* bitbake this recipe directly because we have no interest in the root file system it would produce. We will *only* use the "populate_sdk" task with this recipe.

This gives us the clean target root file system we need *and* the SDK we need.

The disadvantage is that we have to keep two recipe files in sync with each other. Fortunately, these are low-frequency and low-volume changes, so we think this is a reasonable trade-off.