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

[Leo Prikler]

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

Am Donnerstag, den 06.05.2021, 13:03 +0200 schrieb Leo Prikler:
> Am Donnerstag, den 06.05.2021, 12:52 +0200 schrieb Ludovic Courtès:
> > Hi,
> > 
> > Leo Prikler <leo.prikler@student.tugraz.at> skribis:
> > 
> > > Am Mittwoch, den 05.05.2021, 16:16 +0200 schrieb Ludovic Courtès:
> > > > Hi Leo,
> > > > 
> > > > On a cursory look, all three patches LGTM.
> > > > 
> > > > One nit:
> > > > 
> > > > > +                   "exec "
> > > > > +                   (assoc-ref inputs "guile-runtime")
> > > > > +                   "/bin/guile " args)))
> > > > 
> > > > [...]
> > > > 
> > > > >         ("guile" ,guile-3.0)
> > > > >         ("pkg-config" ,pkg-config)
> > > > >         ("texinfo" ,texinfo)))
> > > > > -    (propagated-inputs
> > > > > -     `(("guile-sdl2" ,guile3.0-sdl2)))
> > > > > +    (inputs
> > > > > +     `(("guile-sdl2" ,guile3.0-sdl2)
> > > > > +       ("guile-runtime" ,guile-3.0)))
> > > > 
> > > > 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. 
> 
> Regards,
> Leo