[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: |
Leo Prikler |
Subject: |
[bug#47824] [PATCH 0/3] Happy hacking in the Spring 2021 LGJ |
Date: |
Sat, 15 May 2021 10:35:33 +0200 |
User-agent: |
Evolution 3.34.2 |
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