[bug#40426] [PATCH] Add g-golf

[Mike Rosset]

Christopher Baines writes:

> Vitaliy Shatrov via Guix-patches via <address@hidden> writes:
>
> Does g-golf work with Guile 3 yet? If not, that's OK.
>
Hello Christopher, thanks for looking at this.

  I did quick look at seeing if g-golf would work with guile 3.0. But I
ran into some issue with core module bindings.  Since g-golf very much
WIP and like wise Nomad which is my primary use for g-golf is also
WIP. I've kept strictly to guile 2.2 for now to maintain a little extra
stability. I'll follow up on it when both nomad a g-golf are more
stable.

>
> I'd remove the #:tests? argument given the default value of #t is fine.
>

  Not a problem either myself or Vitality will add a follow up
patch. This was orphaned since we just recently got tests working.

> I don't quite follow this GUILE_GGOLF_UNINSTALLED environment
> variable. Why not just use the absolute filename for the so file
> (without the extension I think)?


  The problem here is that libg-golf is needed both at compile time and
runtime.  So it can not be substituted say after the unpack stage. So
this just checks if GUILE_GGOLF_UNINSTALLED is set.  Then it will
use libg-golf with normal dynamic-link search paths.  Other wise it uses
the full store path.

  I had discussed this scenario with the g-golf author, his
recommendation was to use this approach it's the same one used for the
guile-cv declaration.  He's the author of guile-cv as well.

> Also, maybe delete the strip phase, as I don't think that does anything
> apart from producing a load of warnings.
>

   I think the strip phase strips dynamic elf libraries as well?  I
don't think it would hurt here to keep it for libg-golf at least?

  Would you also be able to look at bug#40512 Christopher? That one is a
trivial review just some upstream bug fixes for Emacsy and a hash bump
in the package declaration.  Technically not related to the patch. But
eventually I'll need both of these when I release the next version of
nomad.

Regards,

Mike