Solving the ‘package-name->name+version’ name conflict. (was: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.)

[Mathieu Lirzin]

Hi,

I am a bit late.

David Thompson <address@hidden> writes:

> * guix/build/emacs-build-system.scm (gnu:unpack)
> (store-file->elisp-source-file, unpack): New procedures.
> (%standard-phases): Use the new unpack procedure.
> ---
>  guix/build/emacs-build-system.scm | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>
> diff --git a/guix/build/emacs-build-system.scm 
> b/guix/build/emacs-build-system.scm
> index f0a9a6e..4fd36d1 100644
> --- a/guix/build/emacs-build-system.scm
> +++ b/guix/build/emacs-build-system.scm
> @@ -21,6 +21,7 @@
>    #:use-module (guix build utils)
>    #:use-module (guix build emacs-utils)
>    #:use-module (srfi srfi-1)
> +  #:use-module (srfi srfi-11)
>    #:use-module (srfi srfi-26)
>    #:use-module (ice-9 rdelim)
>    #:use-module (ice-9 regex)
> @@ -39,6 +40,27 @@
>  ;; archive signature.
>  (define %install-suffix "/share/emacs/site-lisp/guix.d")
>  
> +(define gnu:unpack (assoc-ref gnu:%standard-phases 'unpack))
> +
> +(define (store-file->elisp-source-file file)
> +  "Convert file, a store file name for an Emacs Lisp source file, into a file
> +name that has been stripped of the hash and version number."
> +  (let-values (((name version)
> +                (package-name->name+version
                    ^^^

This is the old ‘package-name->name+version’ from (guix build utils)
which has been replaced when possible by a new one in (guix utils) using
'@' as a delimiter.  While I think it was OK to use it to fix previously
written code, I don't want Guix to build upon the old one.

Time has come to resolve this ugly and confusing name conflict.  The
problem is that I don't fully understand the rationale behind this
temporary solution, so I can't help much.

Ludo: Since you are the mind behind it, I think you are in the best
position to figure this out or at least explain to us “mere mortals”
what is possible and what is not.  :)

-- 
Mathieu Lirzin