[bug#47824,v2,3/3] gnu: tsukundere: Update to 0.3.0.

* gnu/packages/game-development.scm (tsukundere): Update to 0.3.0.
[patch-command]: Patch path to guile.  Construct load paths directly from
inputs.
[propagated-inputs]: Remove.
[inputs]: Add guile (as guile-runtime) and guile-sdl2.
---
 gnu/packages/game-development.scm | 51 +++++++++++++++++++------------
 1 file changed, 32 insertions(+), 19 deletions(-)

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")

Thanks, and congrats to the Lisp Game Jam participants!

Ludo’.

Hi Ludo,

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, so I
assign a "unique" label to the input guile to refer to it.  As a neat
side effect, this label allows me to construct GUILE_LOAD_PATH more
easily.

We already have a number of issues related to the "native-input as
input" thing, "which" returning the wrong binary, and so on, and I
didn't want to add another one on top.  The code I wrote certainly
looks and feels ugly, but I don't see any other way with what Guix
currently provides.  Maybe for the next c-u merge we can do proper
separation of inputs and native-inputs, hopefully using that to clean
up some of our recipes.  

Regards,
Leo

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?

Ludo’.

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

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

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’.

Hi Ludo’,

Am Samstag, den 15.05.2021, 15:45 +0200 schrieb Ludovic Courtès:
> 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?
> 
> [...]
> 
> > > > 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.
Ahh, my bad, it appears I was just confused.  If both native-inputs and
inputs refer to "the same" guile and are on the same architecture, they
should have the same hash, so it doesn't matter, which one is picked. 
I'll try to rewrite the package with that in mind.

Thanks,
Leo