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: Ludovic Courtès
Subject: Re: [PATCH 1/2] build: emacs: Handle sources that are a single elisp file.
Date: Sun, 29 May 2016 23:50:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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?

Thanks,
Ludo’.



reply via email to

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