From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6680389924521246720 X-Received: by 2002:ac2:5088:: with SMTP id f8mr26482876lfm.107.1555572186184; Thu, 18 Apr 2019 00:23:06 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:12c9:: with SMTP id 70ls122263ljs.6.gmail; Thu, 18 Apr 2019 00:23:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVbCyQrcUp/CkCczF/CE2YBOcppODvbNfcfW3zZBGjtap6NCBBfUS9D2M8iMeFBzywBpUX X-Received: by 2002:a2e:3512:: with SMTP id z18mr48948347ljz.25.1555572185655; Thu, 18 Apr 2019 00:23:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555572185; cv=none; d=google.com; s=arc-20160816; b=oOWcgRowu1Fdi8y6oESbaAfbpniX5vuY6bAus4h/TKIbFmFvBxtVkvC9r0nXEd4LC4 tYqgOCPLZ+BXEkh2b3zBfXcTKH0D1xQEN65GJJITZg/Wj0CP3qHaW+7XsTnhpj92k6xe rHjFgCqp/FMzMYlBBnnm8Jh2ww0YNLUja4NXtlnm+oK1QKb1U5cEMpdqDhxDkygjTbnk HHJfsoffhFMJ8xahqmWH2ogvmCH5YNnPcAusYop2M+TdPnr3C26zRB1/gp9eS6kXy67C 7CkCfO6pu5bfLMjRpnzzWyWCaFfKxmqEkMxEEjCm3wtiAJcqNZ3n6kvB1lRBnyBPB9uP wILg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=Y8kkKOvrzYzc03glAhPL+r2qk8BvNPrym8O+UE7V9KM=; b=rJdzh5dgKCxDAvezZFJ/YuGcFiVGuX86aXpy3A8jCR7QqpWYUpDHfE0JrGl6V6w2FO 57KKIE2nvl/6bbZmPbl+qMID1CztH/5SXFYpTvYDsTczw7ELRPuyTaLwIP1WcPENIUbJ 61hGVvoDm0BdOS52WVWAhsqpLN1wrgdeAJ1ZnLc3pN0dME5VOhSPzTMuiQaZ4pw7hO21 Oz5PblTtDcAVgY5WmYyFmAAEp06My4VLqyS4CC8Z3GkcosDyqWDoNgWqUBQHxhJzeGvc pX6XNkYbVEunkJKyg2uQtm+3e5YDrSSYr9OsgZKNq/iu4QoSaTnkRJc4g9qTk2K4ZT2k k3gA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id v21si97427lfg.2.2019.04.18.00.23.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Apr 2019 00:23:05 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x3I7N4sZ008445 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 18 Apr 2019 09:23:04 +0200 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x3I7N44t031148; Thu, 18 Apr 2019 09:23:04 +0200 Subject: Re: Defining the content of the SDK To: "[ext] Jan Kiszka" , isar-users Cc: "Jin, Le (RC-CN DF FA R&D)" References: From: Claudius Heine Message-ID: Date: Thu, 18 Apr 2019 09:23:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: iu3lSPgDx+WG 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