From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7030814154926587904 X-Received: by 2002:a05:600c:a42:: with SMTP id c2mr70834645wmq.154.1637080519155; Tue, 16 Nov 2021 08:35:19 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:80c3:: with SMTP id b186ls1797152wmd.2.gmail; Tue, 16 Nov 2021 08:35:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJxzD1YMAhPyE+47NyZhIlyLnIKSS8M+cHvg3SPr+uxNBVmE4j89Ah5gJKUJOOmHVdEU5NUN X-Received: by 2002:a05:600c:3489:: with SMTP id a9mr21367801wmq.53.1637080518165; Tue, 16 Nov 2021 08:35:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1637080518; cv=none; d=google.com; s=arc-20160816; b=KEmGRH31sIloWt8nqfeJGkMXwvk/viY9Mom9k+GzDUWAObN/aX43FAnINgI7uvBuZD AOx8pVILta5BMnGDztz8xZ/kQyOaHcbFElFeaJW59UrPoz+bAln+J/JqvjgggmDhVspX lpVKhAqfR6tRpRl8xL3avbrogUygNs5tejpVVdOkv+1Ul1aB7qHd3n1DPt+vshYn9CaJ o+Dwdb8nIyXAveMOvnWo8rw1LJCpvL5C4mBKOWyfoBewrjLo+VZrUyel/rkOGINhpbEn mIorUNOmxHtwXIC+IgmYlTsYzVdThEyE8oezLx7OGidsA2BlZDK8SX0SMKvVPx/TQ/ww CWTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=fzOAcLv3w48STjpNnO7neQClE+ptvwCuqtJnOfb6Cq4=; b=IjxdhWnE4gH0i8cydvvBJbKDoBspm8hB30sVdV41SqnVj8AIgBOvmlTJ4QYc9kYZS5 L6csFM6VECvmR3b8Jz3pnL6MfZbGt6CPR+uFfmUR9TL57j0vK7sMua07n7n9xADU7pvV /tBF0RonVo8DgJ70RLXyHR3yJGfbv2rwCsaGRWMhFqaVa8+gmo4R4Il+R9J3SO7bpvvh clUlDxkML77zr2tVk6iAkEzgGCtUWtkTMSHmrd8Mk0HjKS1BZL+pRM8UGXPOOIoawDG+ JHx6O5Js7Uf6Xz4Oeu8NdCvPUiSN+tRujfgF4BopJ/bDiKXSElIvCLeDH7eEVhAKI+8R 4ohA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id c2si342964wmq.2.2021.11.16.08.35.18 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Nov 2021 08:35:18 -0800 (PST) Received-SPF: pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of amikan@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=amikan@ilbers.de Received: from [192.168.67.164] (mm-96-28-214-37.mgts.dynamic.pppoe.byfly.by [37.214.28.96] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 1AGGZFGk007671 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Nov 2021 17:35:16 +0100 Subject: Re: [PATCH] template: Make templates passthrough To: Henning Schild Cc: isar-users@googlegroups.com, Baurzhan Ismagulov References: <20211115150935.153613-1-amikan@ilbers.de> <20211115165745.422c09d9@md1za8fc.ad001.siemens.net> From: Anton Mikanovich Message-ID: <0a7c9626-19f1-14d6-8311-2d2fa67ab7e2@ilbers.de> Date: Tue, 16 Nov 2021 19:35:10 +0300 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: <20211115165745.422c09d9@md1za8fc.ad001.siemens.net> Content-Type: multipart/alternative; boundary="------------1C5A8C5C7742BAACE768790F" Content-Language: en-US X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: BCWIlsNImEJ4 This is a multi-part message in MIME format. --------------1C5A8C5C7742BAACE768790F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 15.11.2021 18:57, Henning Schild wrote: > Does that removal have any side-effects on ... say the fetch task? > If not .. i guess toggeling that KEEP from 0 to 1 would result in "no > such file" Task do_transform_template depends on do_fetch, rebuild after template change scenarios works. Can you give an example of any case where "No such file" issue can happen? >> There is no need to store original template files after the conversion >> in real scenarios. To make working folder little cleaner we can remove >> them. This can be disabled with TEMPLATE_FILES_KEEP variable. > i do not buy the argument and would keep it the way it is ... reject > that patch, but maybe i do not yet get the full picture. > Not the whole patch ... the bits in the custom linux could be valid ... > always keep as with all other templates, unless it makes debian unhappy. > Yes, looks like you don't get the picture. If talking about templates removing in linux-custom, we just move it to bbclass to not mention rm in any recipe needed clean sources. > >> Moreover output file should have exactly the same flags as input one, >> which is usefull for the cases like debian/rules or other executables. >> So we should copy this part of metadata after the conversion. >> >> Signed-off-by: Anton Mikanovich >> --- >> meta/classes/template.bbclass | 7 ++++++- >> meta/recipes-kernel/linux/linux-custom.inc | 3 --- >> 2 files changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/meta/classes/template.bbclass >> b/meta/classes/template.bbclass index fb9d1186..f5760e15 100644 >> --- a/meta/classes/template.bbclass >> +++ b/meta/classes/template.bbclass >> @@ -4,11 +4,12 @@ >> # SPDX-License-Identifier: MIT >> >> TEMPLATE_FILES ?= "" >> +TEMPLATE_FILES_KEEP ?= "0" > Why offer a way at all? And if we do not default to 1, do we need a > changelog entry? > > All in all i think we can keep the files ... always. It is not like > they add a lot of overhead or confusion. And nobody would delete c > files in a Makefile after the .o s are created ... > > regards, > Henning This will not change any recipe API. I've kept TEMPLATE_FILES_KEEP mostly for debugging. Can't think of any real usage of keeping templates inside work dir after the build finish. We do not delete them from the sources, so it can't be compared with removing .c after .o generation. -- Anton Mikanovich Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov --------------1C5A8C5C7742BAACE768790F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
15.11.2021 18:57, Henning Schild wrote:
Does that removal have any side-effects on ... say the fetch task?
If not .. i guess toggeling that KEEP from 0 to 1 would result in "no
such file"

Task do_transform_template depends on do_fetch, rebuild after template change scenarios works.
Can you give an example of any case where "No such file" issue can happen? 

There is no need to store original template files after the conversion
in real scenarios. To make working folder little cleaner we can remove
them. This can be disabled with TEMPLATE_FILES_KEEP variable.

i do not buy the argument and would keep it the way it is ... reject
that patch, but maybe i do not yet get the full picture.
Not the whole patch ... the bits in the custom linux could be valid ...
always keep as with all other templates, unless it makes debian unhappy.

Yes, looks like you don't get the picture.
If talking about templates removing in linux-custom, we just move it to bbclass to not mention rm in any recipe needed clean sources.
 


Moreover output file should have exactly the same flags as input one,
which is usefull for the cases like debian/rules or other executables.
So we should copy this part of metadata after the conversion.

Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
---
 meta/classes/template.bbclass              | 7 ++++++-
 meta/recipes-kernel/linux/linux-custom.inc | 3 ---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/template.bbclass
b/meta/classes/template.bbclass index fb9d1186..f5760e15 100644
--- a/meta/classes/template.bbclass
+++ b/meta/classes/template.bbclass
@@ -4,11 +4,12 @@
 # SPDX-License-Identifier: MIT
 
 TEMPLATE_FILES ?= ""
+TEMPLATE_FILES_KEEP ?= "0"

Why offer a way at all? And if we do not default to 1, do we need a
changelog entry?

All in all i think we can keep the files ... always. It is not like
they add a lot of overhead or confusion. And nobody would delete c
files in a Makefile after the .o s are created ...

regards,
Henning

This will not change any recipe API.

I've kept TEMPLATE_FILES_KEEP mostly for debugging. Can't think of any real usage of keeping templates inside work dir after the build finish.
We do not delete them from the sources, so it can't be compared with removing .c after .o generation.

-- 
Anton Mikanovich
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov
--------------1C5A8C5C7742BAACE768790F--