From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7033292862949163008 X-Received: by 2002:a5d:59ae:: with SMTP id p14mr11657902wrr.365.1637908189395; Thu, 25 Nov 2021 22:29:49 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:770f:: with SMTP id t15ls2516508wmi.3.gmail; Thu, 25 Nov 2021 22:29:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHUvFMsQ9m8JM4Cs4KRy6joM/No/XsmnmHbN6UwYkyggMqGkX0SJ1QEabp2ClRUL2JYSMR X-Received: by 2002:a1c:f416:: with SMTP id z22mr13490175wma.121.1637908188333; Thu, 25 Nov 2021 22:29:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637908188; cv=none; d=google.com; s=arc-20160816; b=jMX8y2/oXyfg6KEdBUgX5EfJnZm1pPQ0IsxV3EMzVPXOHwh3zAEeQTrqpUWbZPi1lv umEPnKERzwIrllMnypN3wVo/GTWo9KPGhUNssGv/FWmWz88GBId4dM6TPrnAJ+qUyWqM vSM/hGjkilHZZoWqXCLXfzCxqWNyZQ9ez+dFmqDlzXx8OjyDzg115Fj6taalp4y+4CMY KWgiiAM6INMvXjwPLQ5cTlDFKXPmiznhw8uff0kNm0t9wZqXOo/+HKrSR/zYr9X6YVqc QXn7IK4SJYWYX/OvGTUBfBGgSsD0k7hPy5QLZOZUvz6iTt+LqRQbCJnl9w+07aCHsQKq ctYQ== 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=HyrCJ+5tvM5amBoMQpr3Cxc+4ldwAZuumT553PK8KAo=; b=WScYhlEIKM738VxlaJRyv4x6MO4f2cldUdab2sSMO7+ulX666ycazCvaAbdAKoECMj LxIKcVMDgft9z0H1yR4v1xjhPuk/wRPno/Ex9IRc3CLMr0ARiBClOZjELVTfhL+2l7tq LNp1g+FcfJfoV74B0e1KORtwRdIkB62grUb7x/KxMVpzZcG2eO8mzCeluWdSiS9Ic21x FNBgNjPMOmGTEtAlo4BGpwcKKOugg87hkfH/Qtv/0pIBTFkgUbnCe3z45RrOD/E5IMdx tXUKUxLWDGoMYNMfadzOCKD5qniTiuyJ/pa1iyv3eW7mVAuvLLQNIUsecHq9Ts35iB5d Uhww== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id u10si489636wrb.5.2021.11.25.22.29.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 22:29:48 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 1AQ6TlIt017357 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 Nov 2021 07:29:47 +0100 Received: from [167.87.0.111] ([167.87.0.111]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1AQ6TlY6024871; Fri, 26 Nov 2021 07:29:47 +0100 Subject: Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions To: vijai kumar Cc: Gylstorff Quirin , 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: Fri, 26 Nov 2021 07:29:47 +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: WN11vRZh6cid On 26.11.21 07:07, vijai kumar wrote: > On Thu, Nov 25, 2021 at 10:04 PM Jan Kiszka wrote: >> >> 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. > > Yes, that also works. But just a bit difficult to read for normal users. It's more Debian-style, thus to be preferred according to Isar principles. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux