public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Claudius Heine <claudius.heine.ext@siemens.com>
To: "[ext] Jan Kiszka" <jan.kiszka@siemens.com>,
	isar-users <isar-users@googlegroups.com>
Cc: "Jin, Le (RC-CN DF FA R&D)" <le.jin@siemens.com>
Subject: Re: Defining the content of the SDK
Date: Thu, 18 Apr 2019 09:23:04 +0200	[thread overview]
Message-ID: <b4b96977-3ca3-d404-7108-c231ad907920@siemens.com> (raw)
In-Reply-To: <d44665ae-c83e-a766-7ff1-9076f75cfc52@siemens.com>

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

      reply	other threads:[~2019-04-18  7:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16  7:24 Jan Kiszka
2019-04-18  7:23 ` Claudius Heine [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4b96977-3ca3-d404-7108-c231ad907920@siemens.com \
    --to=claudius.heine.ext@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=le.jin@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox