From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7033292862949163008 X-Received: by 2002:ac2:518b:: with SMTP id u11mr24745087lfi.498.1637858073526; Thu, 25 Nov 2021 08:34:33 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:2610:: with SMTP id bt16ls533334lfb.2.gmail; Thu, 25 Nov 2021 08:34:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJwwGI0ePeoveyNnEEdO7kUjAPBVLIp1reoQZP5DKCjJCPPiBV67MWMQRX8dEsa9rdYHn0lK X-Received: by 2002:a05:6512:1087:: with SMTP id j7mr25045445lfg.345.1637858072372; Thu, 25 Nov 2021 08:34:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637858072; cv=none; d=google.com; s=arc-20160816; b=ZxfZgFqDxe66/knZZzZnmSzfYg3B2s4ExUnVGxQoUTU0flN3GmldGe8hvtC8zZt85Z sGw8Vg307YDxqWUjBKWTlYIXhjaQvKkUAYWtB3OrBF1gKlj2vCMfXBD9Ob9pGdveNEH2 BJZNlNO0HU6AzZQH0yuNF7NPDUKFgt2AKw/H8agJx9w15TjIPwwSYIr0WbndE0B5zxKn 7GNwWPLdLjjC9FumVkrmrMvADwXmyUtLMVbyVRQm4UNAXsEuL5dN5d4PIb1Z1Pw13ESu tMxrrKT7O3Z9BBCN2mfZ4A3M30xTvLMRH7zxL1Sxgr18Ee8NPUe/Fehe0lfCunTlzv9a 9Hig== 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=w7R8+uTq9TZs9zpNqsEg1fZwVzcez7h9+QYR/EqDHZg=; b=D5o+vQgzcCpxDLI4dc5+8xvUZGP/zzEWT5F5igWvv2XpQ3v9Qb0bpxKcdzQm6gQ4iz kPQOp5DKic+PA5ctsrzfHU33MoOgrnS3hDATG+yk5So1CNrmDR8ECBEQGwBJTDspEDa4 GCE7z7rzH6dCKZc5JYnt25wexP92SWxiuO9GJRYMAyvvdxZNMRYqiCTI80fWywhC35ky YiHroq7kntVQmE1o5Bz7V6db+R3wBoqa8Kq2kDxFZdTmd/ZkNh3GMC3qcj6NeytQn8b3 c/Sq8h3JdRqvC1dSxkpMXOyNgjwoQnPp0HMceMn00oBwe4RU+SfUjA16AOMhv12yRFus 7szA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id t71si266390lff.6.2021.11.25.08.34.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 08:34:32 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 1APGYVSf019256 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Nov 2021 17:34:31 +0100 Received: from [167.87.32.80] ([167.87.32.80]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1APGYUwD027882; Thu, 25 Nov 2021 17:34:30 +0100 Subject: Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions To: vijai kumar , Gylstorff Quirin Cc: Vijai Kumar K , isar-users References: <20211122152607.2125422-1-Vijaikumar_Kanagarajan@mentor.com> <20211122152607.2125422-4-Vijaikumar_Kanagarajan@mentor.com> <8319aef1-420a-034e-9152-b0c3c8c3536a@siemens.com> From: Jan Kiszka Message-ID: Date: Thu, 25 Nov 2021 17:34:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: VLfaag0p8Y7a On 25.11.21 17:27, vijai kumar wrote: > On Thu, Nov 25, 2021 at 12:12 PM vijai kumar > wrote: >> >> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin >> wrote: >>> >>> Hi, >>> >>> On 11/22/21 4:26 PM, Vijai Kumar K wrote: >>>> Newer versions of u-boot require libssl-dev:native for compilation. >>>> It also needs libssl-dev of the host architecture for cross compilation >>>> of tools. >>>> >>>> Signed-off-by: Vijai Kumar K >>>> --- >>>> meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++- >>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc >>>> index 5198809..cfae0e2 100644 >>>> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc >>>> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc >>>> @@ -41,7 +41,9 @@ python() { >>>> d.setVar('U_BOOT_BUILD_PROFILES_remove', "config") >>>> } >>>> >>>> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git" >>>> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native" >>>> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \ >>>> + if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}" >>> >>> Is there are reason why you didn't use `Build-Depends syntax extension` >>> from[1]? >>> >> Hi Quirin, >> >> Yes. There was. The previous version of patch depends on >> ISAR_CROSS_COMPILE as well. >> >> Guess there is nothing stopping us now. But, wondering if we can start >> introducing it via some >> example app with some documentation so that basic users are not >> puzzled on seeing that line in >> a recipe. >> >> Also, we could define a whole new variable to help recipe writers to >> define profiles and seamlessly >> use them without the need to explicitly export DEB_BUILD_PROFILES in >> the recipe's dpkg_runbuild >> >> Now that we are serious enough, we should probably take care of your >> earlier comment >> as well on following the standard. So that we don't conflict with >> Debian's predefined variables in case >> we decided to build a package fetched from apt:// and wanted to make >> use of its profile settings. >> >> Still need to look further but these are my initial thoughts. I could >> probably send some patches for review in >> coming days. >> >> For now, maybe we should call it and use pkg.uboot.tools instead of >> tools here so that we don't >> find something in that implementation that requires us to change this >> in future, possibly breaking >> u-boot / or the need to provide compatibility. >> >> Thoughts? > > OTOH, This could still go in. Since the design I am thinking of is not > finalized and might take some discussions in the list, there is no > point in holding this back. > I think Quirin was just asking for DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \ libssl-dev:native, libssl-dev " rather than using bitbake logic. If that also works, would be more elegant. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux