all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Arun Isaac <arunisaac@systemreboot.net>
To: 26559@debbugs.gnu.org
Subject: bug#26559: [PATCH] build: emacs: Install only a subset of files.
Date: Thu, 20 Apr 2017 18:22:34 +0530	[thread overview]
Message-ID: <628c0262.AEEAJtCcXW0AAAAAAAAAAAO2CuIAAAACwQwAAAAAAAW9WABY-K8Y@mailjet.com> (raw)
In-Reply-To: <877f2fqpeb.fsf@gmail.com>


>>> +                      (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.

>> 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 ? Any other style changes to the code are also
welcome.

> Regarding documentation: note that it is already installed into the
> proper place.  I mean if the package has ".info" files, they are
> installed into "share/info" (look at 'move-doc' procedure in (guix build
> emacs-build-system) module).  For example, 'emacs-debbugs' has the info
> manual and it is installed appropriately.  So I think #:documentation is
> not needed.

Yeah, move-doc is good. I forgot about it.

> 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.

> 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? There are currently 154 packages in
gnu/packages/emacs.scm. Should I test them all?

  reply	other threads:[~2017-04-20 12:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170419073525.2357-1-arunisaac@systemreboot.net>
     [not found] ` <cu7o9vsq1m4.fsf@systemreboot.net>
2017-04-19  7:35   ` bug#26559: [PATCH] build: emacs: Install only a subset of files Arun Isaac
2017-04-19  7:43     ` tumashu
2017-04-19  9:23       ` Arun Isaac
2017-04-19  9:57         ` tumashu
2017-04-19 14:26           ` Arun Isaac
2017-04-20  2:26             ` tumashu
2017-04-20  8:43               ` Arun Isaac
2017-04-20 11:50                 ` Alex Kost
2017-04-19  7:55     ` Arun Isaac
2017-04-20 11:39       ` Alex Kost
2017-04-20 12:52         ` Arun Isaac [this message]
2017-04-22 19:56           ` Alex Kost
2017-04-26 14:20             ` Arun Isaac
2017-05-02 10:10               ` Alex Kost
2017-05-04 18:39         ` Arun Isaac
2017-05-21  9:14           ` Alex Kost
2017-05-21 22:25             ` Ludovic Courtès
2017-05-23  0:48             ` Arun Isaac
2017-04-22 19:57     ` Alex Kost
2017-05-14 13:42       ` Arun Isaac
2017-04-26 14:09     ` bug#26559: [PATCH 1/3] " Arun Isaac
2017-05-04 18:35     ` Arun Isaac
2017-04-19  7:48 ` bug#26560: [PATCH] " Arun Isaac
2017-04-19  7:57   ` Arun Isaac

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=628c0262.AEEAJtCcXW0AAAAAAAAAAAO2CuIAAAACwQwAAAAAAAW9WABY-K8Y@mailjet.com \
    --to=arunisaac@systemreboot.net \
    --cc=26559@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.