From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 03 11:52:20 2022 Received: (at 54221) by debbugs.gnu.org; 3 Mar 2022 16:52:20 +0000 Received: from localhost ([127.0.0.1]:43555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nPogS-0001bq-8N for submit@debbugs.gnu.org; Thu, 03 Mar 2022 11:52:20 -0500 Received: from mx.nixnet.email ([94.16.121.167]:40372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nPogQ-0001bg-4B for 54221@debbugs.gnu.org; Thu, 03 Mar 2022 11:52:06 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mx.nixnet.email (Postfix) with ESMTPSA id E6257200232; Thu, 3 Mar 2022 11:52:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nixnet.email; s=202002021149; t=1646326322; h=from:from:reply-to:subject:subject:to:to:cc; bh=cAvDFXCAKhr6minD9t/JDWUp0u6tRBJ6zxzq2yF/fyA=; b=fNHkzmOkw9jIf38PWmdzEzBvMpECAA/ZCdg7W6clRkWTh+pR5wnIMAJZB2qxshMcXx6OL0 rE0jfD2f9XIh19jyKNDwxbGTjht10tyVtmUl8YszD90nWfiwt4Kczvv8DhT+2B9dRT+uiI C++d9tbv2devxq+awk2pMZSUTNGis8g= Message-ID: Date: Thu, 3 Mar 2022 13:49:44 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [bug#54221] [PATCH 3/4] gnu: vim: Update package style. Content-Language: en-US To: Maxime Devos , 54221@debbugs.gnu.org References: <6002b969ed2f353fef0e8fa87d4fc7d01d3344fa.camel@telenet.be> From: SeerLite In-Reply-To: <6002b969ed2f353fef0e8fa87d4fc7d01d3344fa.camel@telenet.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54221 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, thanks for the review! On 3/2/22 14:29, Maxime Devos wrote: > This is test stuff, and these binaries do not seem to be present in > 'inputs', they would be in the implicit 'native-inputs', so these would > need to search in '(or native-inputs inputs)' instead of 'inputs' to > avoid &search-path exceptions when cross-compiling: > > (substitute* '("src/testdir/...") > (("/bin/sh") (search-input-file (or native-inputs inputs) "bin/sh"))) > > Or simpler, there's a procedure for looking for 'bin/TOOL' in native- > inputs: 'which'! > > ;; the original code! > (substitute* '("src/testdir/...") > (("/bin/sh") (which "sh"))) Whoops, I forgot I made this change. > Why the change from 'which' to 'search-input-file'? The blog post that introduces label-less inputs also introduces 'search-input-file', which made me think they were both part of the "package definition modernization process". I asked on IRC if that was the case, and although I didn't get a clear answer for that, someone told me they preferred using 'search-input-file' because it raises an exception when no file is found. What do you think about that? Should I stick with 'search-input-file' or is 'which' alright? It makes sense that I'd have to use native-inputs though. My bad!