Defining the content of the SDK

Defining the content of the SDK

[Jan Kiszka]

Hi all,

we are just looking more closely at the SDK Isar can generate, and that in the 
context of a concrete target. It quickly became clear that we miss a lot of 
packages and also configurability.

Currently, there is a hard-coded SDKCHROOT_PREINSTALL that defines which 
additional packages, besides the core toolchain, should go into the SDK. 
However, if you have libfoo on your target, you possibly want libfoo-dev in your 
SDK in order to develop against that.

Now the question is if it could be sufficient to derive the required -dev 
packages from the target image or if we should rather or additionally allow to 
augment the installed package set. Is there any simple pattern we can inherit 
from OE?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: Defining the content of the SDK

[Claudius Heine]

Hi Jan,

On 16/04/2019 09.24, [ext] Jan Kiszka wrote:
> Hi all,
> 
> we are just looking more closely at the SDK Isar can generate, and that 
> in the context of a concrete target. It quickly became clear that we 
> miss a lot of packages and also configurability.
> 
> Currently, there is a hard-coded SDKCHROOT_PREINSTALL that defines which 
> additional packages, besides the core toolchain, should go into the SDK. 
> However, if you have libfoo on your target, you possibly want libfoo-dev 
> in your SDK in order to develop against that.
> 
> Now the question is if it could be sufficient to derive the required 
> -dev packages from the target image or if we should rather or 
> additionally allow to augment the installed package set. Is there any 
> simple pattern we can inherit from OE?

Well the main difference we have is that OE creates the SDK in the image 
recipe and Isar has the sdkchroot recipe which creates the SDK and just 
a task that copies from there in the image recipe.

Since one recipe cannot control the variables from another one, we would 
need to implement a customization mechanism similar to what we already 
do to the root file system of the image. Maybe we could try to reuse the 
functions that are implemented in my 'pre-processing pipeline and 
transient package replacement' patchset, once that is merged.

Then we can think of ways to figure out which packages needs to be 
installed to the sdk.

I suppose every '-dev' package of the packages deployed to the image as 
well as the foreign architecture binary packages. We also have to think 
about how to handle the build dependencies. Should we deliver the build 
dependencies of every package or just the ones that are needed by the 
packages build by Isar?

Claudius

> 
> Jan
> 

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de