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

["Denys Dmytriyenko" <denis@denix.org>]

On Fri, May 07, 2021 at 09:49:32AM -0700, Andre McCurdy wrote:
> On Fri, May 7, 2021 at 6:47 AM Robert P. J. Day <rpjday@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.

Exactly! Thanks for this excellent summary!

I've heard so many times before that my meta-toolchain recipe is not the 
"Yocto" way of doing things and I should instead use populate_sdk. I got 
tired arguing with people and explaining that meta-toolchain is quite valid 
and has its merits...

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964