GNU bug report logs - #47824
[PATCH 0/3] Happy hacking in the Spring 2021 LGJ

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 47824 <at> debbugs.gnu.org, efraim <at> flashner.co.il
Subject: [bug#47824] [PATCH 0/3] Happy hacking in the Spring 2021 LGJ
Date: Sat, 15 May 2021 15:45:35 +0200

Hi Leo,

Leo Prikler <leo.prikler <at> student.tugraz.at> skribis:

> For the record, I've pushed guile-sdl and chickadee already, any hints
> w.r.t. the problem in Tsukundere?

[...]

>> > > > I think it’s best to not play trick with labels, and to always
>> > > > use
>> > > > the
>> > > > package name as the label (to facilitate migration on the day
>> > > > where
>> > > > we
>> > > > get rid of labels, who knows…).
>> > > > 
>> > > > A common pattern for the case above is to provide “guile” both
>> > > > as
>> > > > native
>> > > > input and input, and to write:
>> > > > 
>> > > >   (assoc-ref (or native-inputs inputs) "guile")
>> > > What I'm doing here is the exact opposite.  I don't want the
>> > > omnipresent native-input guile to shadow the guile I use as
>> > > input,
>> > 
>> > In that case, you can unconditionally do:
>> > 
>> >   (assoc-ref inputs "guile")
>> > 
>> > Unless I’m mistaken, it won’t be shadowed by the native input
>> > “guile”
>> > when cross-compiling.
>> > 
>> > Or am I missing something?
>> Perhaps it's an implementation detail, that when performing native
>> builds, inputs are merged as (append inputs native-inputs), but they
>> could as well be (append native-inputs inputs).  I'd have to check,
>> and
>> I'm not sure whether I want to rely on that detail. 

I didn’t see a question mark, which is why I didn’t answer.  :-)

I fail to see why (assoc-ref inputs …) wouldn’t work.

Thanks,
Ludo’.

Previous Next

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