[bug#48729,v2,05/47] gnu: Add go-github-com-keybase-go-ps.

* gnu/packages/golang.scm (go-github-com-keybase-go-ps): New variable.
---
 gnu/packages/golang.scm | 37 +++++++++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

Raghav Gururajan via Guix-patches via schreef op do 03-06-2021 om 05:57 [-0400]:
> +         (modify-phases %standard-phases
> +           (add-after 'unpack 'fix-tests
> +             (lambda* (#:key inputs #:allow-other-keys)
> +               (substitute* (find-files "." ".*test\\.go")
> +                 (("/bin/sleep")
> +                  (string-append (assoc-ref inputs "coreutils")
> +                                 "/bin/sleep")))

When cross-compiling, coreutils is not in 'inputs', but in 'native-inputs', right?
So this would lead to a build error when cross-compiling.
(assoc-ref inputs "coreutils") would return #f, thus you'd get an exception

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure string-append: Wrong type (expecting string): #f

I would make this (untested):

  (sring-append (assoc-ref (or native-inputs inputs) "coreutils") "/bin/sleep")

Greetings,
Maxime.

Hi Maxime!

> When cross-compiling, coreutils is not in 'inputs', but in 'native-inputs', right?
> So this would lead to a build error when cross-compiling.
> (assoc-ref inputs "coreutils") would return #f, thus you'd get an exception
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure string-append: Wrong type (expecting string): #f

I am confused. It is used only during check phase (which is build-time), 
so when cross-compiling, the arch for build machine is used for 
native-inputs right?

I wonder how other native-inputs like gettext etc doesn't give this error.

> I would make this (untested):
> 
>    (sring-append (assoc-ref (or native-inputs inputs) "coreutils") "/bin/sleep")

Thanks!

Regards,
RG.

Raghav Gururajan schreef op vr 11-06-2021 om 00:17 [-0400]:
> Hi Maxime!
> 
> > When cross-compiling, coreutils is not in 'inputs', but in 'native-inputs', right?
> > So this would lead to a build error when cross-compiling.
> > (assoc-ref inputs "coreutils") would return #f, thus you'd get an exception
> > 
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > In procedure string-append: Wrong type (expecting string): #f
> 
> I am confused. It is used only during check phase (which is build-time), 
> so when cross-compiling, the arch for build machine is used for 
> native-inputs right?

The Go build system doesn't support cross-compilation currently.
So, for explanation, let's assume gnu-build-system instead.

The issue is that, when cross-compiling, 'inputs' consists solely
of the packages listed in the 'inputs' field of the package definition
(When compiling natively, 'native-inputs' is merged into 'inputs'.)

As "coreutils" is not in "inputs", it follows that that (assoc-ref inputs "coreutils")
returns #f. Thus, when (string-append (assoc-ref inputs "coreutils") "/bin/sleep")
is executed, it raises an exception, as string-append expects strings only.
Now, about:

> I am confused. It is used only during check phase (which is build-time), 
> so when cross-compiling, [...]

The [...]/bin/sleep binary is only used during the check phase (and therefore
ignored when cross-compiling), yes, but the (string-append [...]) is _always_
executed!

> so when cross-compiling, the arch for build machine is used for native-inputs,
> right?

Yes.

> I wonder how other native-inputs like gettext etc doesn't give this error.

There's very little code doing (assoc-ref inputs "gettext"),
(assoc-ref native-inputs "gettext") or (assoc-ref native-inputs "gettext")
in Guix. The only case I found:

   # cargo-build-system
  (when (assoc-ref inputs "gettext")
    (setenv "GETTEXT_SYSTEM" (assoc-ref inputs "gettext")))

So, I'm not sure what you're referring to.

Simply including gettext in native-inputs doesn't cause an error.

It it trying to (string-append (assoc-ref inputs "gettext") "stuff") that
raises an error when 'gettext' is not in 'inputs' or 'native-inputs' when compiling natively,
or when 'gettext' is not in 'inputs' when cross-compiling,
as in these cases, (assoc-ref inputs "gettext") returns #f.

Greetings,
Maxime.

Hi Maxime!

>> I am confused. It is used only during check phase (which is build-time),
>> so when cross-compiling, the arch for build machine is used for
>> native-inputs right?
> 
> The Go build system doesn't support cross-compilation currently.
> So, for explanation, let's assume gnu-build-system instead.
> 
> The issue is that, when cross-compiling, 'inputs' consists solely
> of the packages listed in the 'inputs' field of the package definition
> (When compiling natively, 'native-inputs' is merged into 'inputs'.)
> 
> As "coreutils" is not in "inputs", it follows that that (assoc-ref inputs "coreutils")
> returns #f. Thus, when (string-append (assoc-ref inputs "coreutils") "/bin/sleep")
> is executed, it raises an exception, as string-append expects strings only.
> Now, about:
> 
>> I am confused. It is used only during check phase (which is build-time),
>> so when cross-compiling, [...]
> 
> The [...]/bin/sleep binary is only used during the check phase (and therefore
> ignored when cross-compiling), yes, but the (string-append [...]) is _always_
> executed!
> 
>> so when cross-compiling, the arch for build machine is used for native-inputs,
>> right?
> 
> Yes.
> 
>> I wonder how other native-inputs like gettext etc doesn't give this error.
> 
> There's very little code doing (assoc-ref inputs "gettext"),
> (assoc-ref native-inputs "gettext") or (assoc-ref native-inputs "gettext")
> in Guix. The only case I found:
> 
>     # cargo-build-system
>    (when (assoc-ref inputs "gettext")
>      (setenv "GETTEXT_SYSTEM" (assoc-ref inputs "gettext")))
> 
> So, I'm not sure what you're referring to.
> 
> Simply including gettext in native-inputs doesn't cause an error.
> 
> It it trying to (string-append (assoc-ref inputs "gettext") "stuff") that
> raises an error when 'gettext' is not in 'inputs' or 'native-inputs' when compiling natively,
> or when 'gettext' is not in 'inputs' when cross-compiling,
> as in these cases, (assoc-ref inputs "gettext") returns #f.

Thanks so much for the explanation. I understood it now. :)

I have added your suggestion in v5.

Regards,
RG.