GNU bug report logs - #54221
[PATCH 0/4] vim: Detect plugins via search paths.

Previous Next

Full log

Message #38 received at 54221 <at> debbugs.gnu.org (full text, mbox):

From: SeerLite <seerlite <at> nixnet.email>
To: Maxime Devos <maximedevos <at> telenet.be>, 54221 <at> debbugs.gnu.org
Subject: Re: [bug#54221] [PATCH 3/4] gnu: vim: Update package style.
Date: Thu, 3 Mar 2022 13:49:44 -0300

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!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.