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

["Ludovic Courtès" <ludo@gnu.org>]

Hi Leo,

Leo Prikler <leo.prikler@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’.