Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.

[Alex Kost]

Ludovic Courtès (2016-05-30 00:50 +0300) wrote:

> Alex Kost <address@hidden> skribis:
>
>> Ludovic Courtès (2016-05-28 18:36 +0300) wrote:
>>
>>> David Thompson <address@hidden> skribis:
>>>
>>>> * guix/build/emacs-build-system.scm (gnu:unpack)
>>>> (store-file->elisp-source-file, unpack): New procedures.
>>>> (%standard-phases): Use the new unpack procedure.
>>>
>>> Good idea, LGTM!
>>>
>>> Could you adjust users of ‘uncompressed-file-fetch’ in a subsequent
>>> commit, and remove ‘uncompressed-file-fetch’?
>>
>> I object!
>
> Damn it, sorry, I thought this would be uncontroversial.
>
>> I mean this should be discussed at least.  I would really prefer to
>> keep (and document) 'uncompressed-file-fetch' and not to update
>> emacs-build-system for this case.  It is possible, that once we'll
>> need to handle non-compressed files for another build system.  So it
>> should also be adjusted in the same way.  But if we keep
>> 'uncompressed-file-fetch', it will be a general decision as it can be
>> used for any build system.
>
> In my view, ‘uncompressed-file-fetch’ and the ‘emacs-build-system’
> change that Dave proposes are equally good hacks, but the latter has the
> advantage that people won’t have to think about it: they can just use
> ‘url-fetch’ and ‘emacs-build-system’ as usual and things will just work.
>
> Of course, perhaps we should consider handling flat files closer to the
> core, but so far the only use case we have, AFAIK, is .el files.  Thus,
> it doesn’t seem that bad to add a special case in ‘emacs-build-system’.
> Pragmatic approach I suppose.  ;-)
>
> WDYT?

<cough>, OK, I wanted to write verbosely why I prefer
uncompressed-file-fetch, and why we should still use it, etc.;

but I've just noticed an unpleasant downside with
‘uncompressed-file-fetch’: for example, if you build the recently added
"emacs-queue" package, you'll get "queue-0.1.1.el" file, which makes it
impossible to do (require 'queue).  With David's solution, it will be a
proper "queue.el" file.

So I agree now.  David's patch is definitely a better solution :-)

-- 
Alex