Ludovic Courtès (2016-05-30 00:50 +0300) wrote: > Alex Kost <alez...@gmail.com> skribis: > >> Ludovic Courtès (2016-05-28 18:36 +0300) wrote: >> >>> David Thompson <dthomps...@worcester.edu> 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
