Maxime Devos <maximedevos@telenet.be> writes:

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

I see.  I am not yet familiar with the --with-input flag.  I will
explore this feature, thank you.

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

I see a double-quote there with ~''(:pamixer)~ - which is not something
I have ever tried to do before.  Is this a typo?

I had tried (list #:asd-systems '(:pamixer) #:phases #~([...])) and the
build failed due '(:pamixer) somehow not returning anything from a (car)
function.

Sometimes errors elsewhere cause nebulous tracebacks.  I will try this again.

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

I like the new way of using gexps.  They are more terse than needing to
assoc reference inputs/outputs.  The thought of as slow transition
happening had occured to me.  I appreciate your insight.

-- 

Trev : 0FB7 D06B 4A2A F07E AD5B  1169 183B 6306 8AA1 D206