Re: [OE-core] SDK question: does "-c populate_sdk" build SDK based on entire image?

["Diego Santa Cruz" <diego.santacruz@spinetix.com>]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> core@lists.openembedded.org> On Behalf Of Robert P. J. Day via
> lists.openembedded.org
> Sent: 07 May 2021 15:12
> To: OE Core mailing list <openembedded-core@lists.openembedded.org>
> Subject: [OE-core] SDK question: does "-c populate_sdk" build SDK based on
> entire image?
> 
> 
>   almost certainly a silly question as i'm still poring over the
> mechanics of standard SDK creation, but if i define a perfectly normal
> image, then build the corresponding SDK with:
> 
>   $ bitbake -c populate_sdk my_image
> 
> is the resulting SDK populated based on the entire contents of the
> target image? that is, if i subsequently add a new package to the
> target and rebuild the SDK, will the new SDK now contain the
> corresponding content from that newly-added package? (i'm just about
> to test this with a build but that's going to take over an hour on
> this server. *sigh* ...)

We use the SDK a lot to give application developers an easy to use a dev environment which has all the support to build against the libraries included in target images. The SDK of an image recipe will contain all the *-dev packages matching the packages installed in the target for the same image (i.e. if foobar is installed in the target image then foobar-dev is installed in the SDK image, if it exists).

> 
>   now, i realize that if i just want to add content to the SDK without
> adding to target, i can use one or both of:
> 
>   TOOLCHAIN_HOST_TASK
>   TOOLCHAIN_TARGET_TASK
> 
> but if someone asks for new content both for the target and the SDK,
> is it sufficient to just add to target?

Yes, with the exception of recipes for which only the headers are used when compiling a recipe that is included in the target image. As no library is being linked for it then no package is installed into the target, so no corresponding *-dev package is included in the SDK. A typical example of this is boost when the header-only boost libs are used (and I suspect the same happens for static libs). In such a case you can add the recipes to TOOLCHAIN_TARGET_TASK (we actually have an sdk packagegroup that we add to TOOLCHAIN_TARGET_TASK that pulls in all target SDK things that we want in the SDK but not in the target image).

Other things that you may need to add manually to TOOLCHAIN_HOST_TASK are supporting tools to run on the build host which are not included in the SDK by default, like nativesdk-glib-2.0-codegen to get the gdbus-codegen utility.

> 
>   and one more question that inspired all of this. i was asked to add
> a particular executable to an SDK, call it /usr/bin/fubar. fair
> enough, i thought, it was short work to determine that that binary
> came from the recipe fubar_1.0.bb. but i checked and that package was,
> in fact, being installed in the target, so i was puzzled as to why it
> wasn't in the SDK as well.
> 
>   i checked the recipe for fubar and, to my chagrin, it contained the
> snippet:
> 
>   do_install_append() {
>     rm -rf ${D}/usr/bin/fubar
>   }
> 
> well, that explained it, so as a first test, i'm just going to dump
> that snippet from the recipe, which will install the executable on the
> target, and will(?) also install it in the SDK?
> 
> rday
-- 
Diego Santa Cruz, PhD
Technology Architect
spinetix.com