guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thompson, David
Subject: Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.
Date: Mon, 30 May 2016 11:12:23 -0400

On Mon, May 30, 2016 at 6:14 AM, Alex Kost <address@hidden> wrote:
> 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 :-)

Hehe.  Thanks for the discussion.  Pushed!

- Dave



reply via email to

[Prev in Thread] Current Thread [Next in Thread]