[bug#57757] [PATCH] gnu: Add sbcl-stumpwm-pamixer

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2337 bytes --]

On 19-09-2022 20:22, Trev wrote:
> Maxime Devos <maximedevos@telenet.be> writes:
> 
>> On 19-09-2022 19:47, Trevor Richards wrote:
>>> +      (arguments
>>> +       `(#:asd-systems '(:pamixer)
>>> +         #:phases
>>> +         ,#~(modify-phases %standard-phases
>>> +             (add-after 'unpack 'patch-pamixer
>>> +               (lambda _
>>> +                 (substitute* "pamixer.lisp"
>>> +                   (("\"pamixer \"")
>>> +                    (string-append
>>> +                     "\"" #$pamixer "/bin/pamixer \""))))))))
>>
>> To support --with-input transformations, you can't do #$input, you have
>> to do #$(this-package-input "pamixer") instead -- or better, don't
>> depend on input labels, by using (search-input-file inputs
>> "bin/pamixer") instead.
>>
> 
> Thanks for the feedback. It's hard to tell when a gexp is appropriate
> and where it's not, or how to properly evaluate it all at the right
> time. The current patch builds. Is this problematic in the sense that
> it's using some reference to #$pamixer that is not actually a part of
> the build environment?

It is inappropriate in the sense that '--with-input' rewrites the 
'inputs', 'native-inputs' and 'propagated-inputs' fields, but not the 
contents of the G-exp.

> Note I had to use a quasiqote and unquote for the `gexp` to work.
> Transforming the arguments into a list so I would not have to do this
> breaks the #:asd-systems keyword value somehow.

How about:

(arguments
   (list #:asd-systems ''(:pa-mixers)
         #:phases
         #~(modify-phases [...])))

(i.e., you are removing a layer of quoting by turning the quasiquote 
into a quote, so it needs to be readded for the #:asd-systems).

> 
> When I observe the source code it's kinda all over the place when it
> comes to using gexps in some way or when not to.
> 
> I will patch this again and document a note about this but if there's
> any clarifying documentation I would happily read it. Apologies in
> advance if I have missed existing documentation.

I'm not aware of any, though I'd like to note that G-exps are new-ish 
and hence the 'all over the place' is more "guix style doesn't know how 
to transform this kind of old thing yet" than "we chose for s-exps 
instead of G-exps".

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]