From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 65D2345AC4; Sun, 6 Oct 2024 10:55:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F2D034025D; Sun, 6 Oct 2024 10:55:20 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id AC936402A1 for ; Sun, 6 Oct 2024 10:55:19 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 556D2C6E0 for ; Sun, 6 Oct 2024 10:55:19 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 49BB8C6DF; Sun, 6 Oct 2024 10:55:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.85] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id ACC51C79D; Sun, 6 Oct 2024 10:55:16 +0200 (CEST) Message-ID: <722ddf9d-29ed-4d3b-bc54-ac2aafefd2bb@lysator.liu.se> Date: Sun, 6 Oct 2024 10:55:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 1/7] buildtools/chkincs: relax C linkage requirement To: Robin Jarry , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org Cc: Heng Wang , Stephen Hemminger , Tyler Retzlaff , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Jack Bond-Preston , David Marchand , Chengwen Feng References: <20240920062437.738706-2-mattias.ronnblom@ericsson.com> <20240920104754.739033-1-mattias.ronnblom@ericsson.com> <20240920104754.739033-2-mattias.ronnblom@ericsson.com> <74e86a66-4341-465d-bcba-d76db66035cd@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2024-10-04 13:51, Robin Jarry wrote: > Mattias Rönnblom, Oct 04, 2024 at 10:40: >> Making small scripts needlessly complicated is not good example, it's >> a bad one. > > I don't find adding argument checks needlessly complicated but this is a > matter of preference. To me, Python is not shell script. If you want > something small, shell might be more appropriate? > Python can serve in many roles. I suggest you be more pragmatic and sensitive to the context. Sometimes the non-existence/non-use of doc strings and other language features that makes sense in larger programs is not a sign of the author being out to "treat Python badly". >>>> Sure, but it would be required to invoke the script for every header >>>> file in the tree. Not sure I think that would be a net gain. >>> >>> You can store a global exit status in the script and process all >>> headers before exiting with an error if any. >> >> You will need to give the user a list of offending header files. > > I'm not suggesting to avoid printing the offending file names. I'm only > suggesting to exit(1) if there were *any* offending file names. That way > you don't have to check *in meson* if the script did output anything. > Checking the exit status is simpler. > What you wrote was "/../ That way you would not have to capture stdout at all and you could leave meson do the work.". Can you elaborate on this? I'm not sure I follow. Is there a way to not capture the script output, invoke the script only once per build, and yet produce a fine-grained error message to the user? I agree properly setting the exit code is an improvement. I just don't see how that materially changes anything on the meson side of things. But then, I know nothing about meson. > Sorry for being pedantic, but Python code in DPDK is already treated > badly. I wish we could improve the quality a bit. > > Cheers. >