> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-
> c...@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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151613):
https://lists.openembedded.org/g/openembedded-core/message/151613
Mute This Topic: https://lists.openembedded.org/mt/82654706/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
