[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#47824] [PATCH 0/3] Happy hacking in the Spring 2021 LGJ
From: |
Ludovic Courtès |
Subject: |
[bug#47824] [PATCH 0/3] Happy hacking in the Spring 2021 LGJ |
Date: |
Sat, 15 May 2021 15:45:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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’.