RE: [PATCH] sdk: make SDK and image

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

Kiszka, Jan, 15. Dezember 2021 10:20
> On 15.12.21 09:43, Henning Schild wrote:
> > Am Wed, 15 Dec 2021 09:38:24 +0100
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >
> >> On 15.12.21 09:07, Schmidt, Adriaan (T RDA IOT SES-DE) wrote:
> >>> Kiszka, Jan (T RDA IOT), 15. Dezember 2021 08:52:
> >>>> On 15.12.21 07:41, Adriaan Schmidt wrote:
> >>>>> This derives the SDK from image.bbclass (currently it only
> >>>>> inherits rootfs), removing the awkward and custom tar-xz'ing.
> >>>>> 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.
> >>>>>
> >>>>> API change: SDK is now no longer built using `bitbake my_image
> >>>>>     -cpopulate_sdk`, but using `bitbake isar-sdk`. We could of
> >>>>> course keep the old commands working, but I could not find any
> >>>>>     connection between the target image and the contents of the
> >>>>> SDK (while building the SDK using the target image recipe
> >>>>> confusingly makes it look like there is such a connection).
> >>>>
> >>>> This is not correct: The target image recipe may define
> >>>> SDK_[PRE]INSTALL in correspondance to its content. Also, changing
> >>>> the user API would needlessly break the alignment with OE.
> >>>
> >>> But the SDK is built by a completely different recipe (sdkchroot,
> >>> inheriting rootfs), so how does SDK_[PRE]INSTALL set in the target
> >>> image recipe have any effect there? Looks to me that those
> >>> variables need to be set in some .conf for this to work, but maybe
> >>> I'm missing something...
> >>
> >> Well, if that is the case now, we indeed have a bug. But the fixing
> >> direction should be along that line "image defines SDK", not "SDK is
> >> something completely different".
> >
> > NACK. If we have that bug we can apply that patch to enable my series,
> > and deal with that bug later.
> 
> NACK for user-visible API changes - if we fix something internally
> without breaking how a user triggers the build, then this is fine. But
> we must not fix in the wrong direction, like this patch is suggesting.

Preserving -cdo_populate_sdk for the user is trivial, will propose v2.

Unfortunately, while my patch preserves implemented behavior w.r.t SDK
content, it takes the SDK a little further away from its intended behavior,
which could make fixing the bug afterwards more difficult. But that fix
will certainly be non-trivial, so I'm ok with postponing.

Adriaan