RE: [PATCH v2] sdk: make SDK an image

["Schmidt, Adriaan" <adriaan.schmidt@siemens.com>]

Kiszka, Jan, 15. Dezember 2021 12:55:
> On 15.12.21 11:55, Adriaan Schmidt wrote:
> > This derives the SDK from image.bbclass (currently it only
> > inherits rootfs), removing the custom packaging, and instead
> > relying on existing features of image.bbclass.
> > Note that because there is not tarxz-img IMAGE_TYPE, we switch
> > the SDK type to targz-img. This is only temporary, until we have
> > the OE-inspired imagetypes.
> 
> Then the ordering is also wrong: First make sure we can keep the
> previous output format, then refactor.
> 
> Meanwhile, we can think about how to hook the SDK image build into a
> task of another image build, so that we move in the right direction /wrt
> configuration.

I had a look at OE. There the SDK is something generated by the target
image, but it's something quite complex, with lots of Python code and
stuff in libraries. But except for the Isar SDK being simpler, it's
following the same idea.

I now think:
- The SDK should be generated by the target image recipe, but maybe
  more integrated than it currently is. (Put the logic currently in
  the sdkchroot recipe into the image-sdk-extension class, so we can
  easily use settings made in the target image recipe)
- The SDK should only be generated as tar[xz|gz], but not as container
- If someone wants an SDK image (container, development VM, ...),
  that would be a separate recipe further processing the SDK, and the
  user would need to create that recipe explicitly. I can imagine that
  for the default case, this SDK image recipe would only have two lines:
  include the target image recipe (to get all the SDK_* settings and the
  do_populate_sdk task) and include some new class that makes the
  adjustments to generate an "image containing the SDK" instead
  of the original target image.

Adriaan