bug#26559: [PATCH] build: emacs: Install only a subset of files.

[Alex Kost]

Arun Isaac (2017-04-20 18:22 +0530) wrote:

>>>> +                      (include ''(".*.el$" ".*.el.in$" "^dir$"
>>>> +                                 ".*.info$" ".*.texi$" ".*.texinfo$"
>>>> +                                 "doc/dir" "doc/*.info$" "doc/*.texi$" 
>>>> "doc/*.texinfo$"))
>>>> +                      (exclude ''("^.dir-locals.el$" "^test.el$" 
>>>> "^tests.el$" ".*-test.el$" ".*-tests.el$"))
>>>
>>> I've copied all this from MELPA's default :files property described at
>>> https://github.com/melpa/melpa . I have no idea what the rationale for
>>> some of these regexes are.
>>
>> What regexps are not clear for you?
>
> I don't understand what ".*.el.in$", "^dir$" and "doc/dir" are for.

"dir" file is for documentation (to make the according manual entry
appear in the top Info directory).  These "dir" files are not needed for
Guix, as Guix generates "dir" after updating a profile
("<guix-profile>/share/info/dir").

Usually files with ".in" ending are used as templates to generate other
files from them (in this case ".el" from ".el.in").  It looks like there
are packages that have ".el.in" files but not ".el" files, and
package-build (used by melpa) just renames such files.  At least that's
what I understood from:

  
https://github.com/melpa/package-build/commit/d1c217a7ef33807c4948853114133af72284031c

But I'm sure we don't have the packages with ".el.in" files, and if we
will, most likely gnu-build-system will be used for them, so I suggest
to remove ".el.in" regexp from the "include" list.

>>> Currently, include and exclude are a list of regexes that file names are
>>> matched against. Should this be combined into one big regex?
>>
>> I think it is not needed, it is more clean to separate regexps.
>
> Ok. Also, please suggest better names if #:include and #:exclude are not
> clear. Perhaps #:include-files and #:exclude-files, or #:install-files
> and #:no-install-files ?

I think include/exclude is OK.  But maybe other people (if anyone else
reads this thread :-)) have other opinions.

[...]
>> Also I would like to note that this patch (when it will be ready)
>> shouldn't be committed alone: there are some emacs packages that should
>> be adjusted to include additional files.  One that comes to mind is
>> 'emacs-slime' - it *must* contain *.lisp files (and other files as
>> listed at <https://github.com/melpa/melpa/blob/master/recipes/slime>).
>> Otherwise, it wouldn't work at all.
>
> For specific packages, we can always override the #:include and
> #:exclude keyword arguments. Or, even replace the 'install phase if it
> comes to that.

Yes, that's what I meant.

>> So I think this patch should be committed with the according fixes for
>> such "complex" packages (not sure if there are other ones along with
>> 'emacs-slime').
>
> Is there some standard workflow for testing packages when there is a
> build system change?

AFAIK, there is no standard workflow :-)

> There are currently 154 packages in
> gnu/packages/emacs.scm. Should I test them all?

I think it would be too much work.  I quickly looked at the emacs
packages, and I believe that only slime, auctex and yasnippet need to be
adjusted to include non-standard files.  Of course, there may be other
packages that I'm not aware of, but they can be fixed later.

-- 
Alex