On Fri, May 7, 2021 at 6:47 AM Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>
> On Fri, 7 May 2021, Quentin Schulz wrote:
>
> > Hi Robert,
> >
> > No SDK expert here, so as usual, to be taken with a grain of salt.
> >
> > On Fri, May 07, 2021 at 09:11:37AM -0400, Robert P. J. Day wrote:
> > >
> > > 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* ...)
> > >
> >
> > I think you're mixing SDK and eSDK. AFAIU so far, you're looking for
> > an eSDK. An SDK just gives you the minimal toolchain and associated
> > tools, to be able to compile something. I would go as far as saying
> > it's basically what a PC distro package for cross-compile with gcc
> > is doing.
>
> ... snip ...
>
> it's slowly coming back to me, as i once examined the recipe
> meta-toolchain.bb for building a toolchain, whose contents are
> effectively:
>
> inherit populate_sdk
>
> and when you run "bitbake meta-toolchain", you're obviously not
> supplying a particular image as an argument, so whatever is being done
> has to be based on fundamental information like MACHINE and so on,
> with no reference to a particular image so, yes, you'd get a "minimal"
> toolchain as you describe above independent of any image.
>
> however, as populate_sdk.bbclass inherits populate_sdk_base.bbclass,
> and that latter class file contains:
>
> TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host
> packagegroup-cross-canadian-${MACHINE}"
> TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
> TOOLCHAIN_TARGET_TASK ?= "${@multilib_pkg_extend(d,
> 'packagegroup-core-standalone-sdk-target')} target-sdk-provides-dummy"
> TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
> TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
>
> it seems clear that you can augment that minimal toolchain with
> exactly the two variables i mentioned earlier. ok, i think i've
> refreshed my memory on this. now off to figure out the eSDK.
Didn't we discuss exactly this (ie the difference between a pure SDK
recipe such as meta-toolchain and the populate_sdk task of an image
recipe) a couple of weeks ago?
Both are valid ways to create an SDK and there are no rules about one
or the other being specific to creating a "minimal" toolchain.
Basically a pure SDK recipe gives you full control while the
populare_sdk task of an image recipe is easier to set up (no new
recipe to write) at the expense of the final SDK containing extra junk
such as busybox init scripts, etc which are needed in the image but
not an SDK.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151460):
https://lists.openembedded.org/g/openembedded-core/message/151460
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]
-=-=-=-=-=-=-=-=-=-=-=-
