unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jackson Ray Hamilton <jackson@jacksonrayhamilton.com>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: [elpa] master 580a1b6: Respect .elpaignore when compiling and optimize compilation.
Date: Mon, 26 Dec 2016 11:57:22 -0800	[thread overview]
Message-ID: <318da984-8e21-fece-3d61-2e3846a1cef6@jacksonrayhamilton.com> (raw)
In-Reply-To: <jwvzijjba52.fsf-monnier+emacsdiffs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

> I haven't looked at the performance side of this.  It just seemed simpler.

I say we keep it as-is, as my reading of the current commands is simpler
than the way I read this alternative.  Compare the way I read it: "Make
a tar archive and list its contents."  Versus: "Execute tar with verbose
output, which happens to only include the files packaged, also that
output needs to be redirected from stderr to stdout for make to process
it, also bury the archive contents in /dev/null so as not to interfere
with the redirected verbose output."

> No, I was rather wondering if this behavior is documented or just accidental.

Although I do not see an example of an explicitly mentioned file
argument used with an exclusion flag in the tar manual, the language of
the manual suggests that this should work:

>  `--exclude-from=file'
> `-X file'
> 
>     Causes tar to ignore files that match the patterns listed in file. 

"Files" ought to include explicitly mentioned files.

Also, I've attached a patch for the "pwd-based exclusions" issue I
mentioned in my last email.  I checked the timing on it, and it only
reduces the speed of "make" with nothing to do by about 50ms.  Does it
look good to you?

Jackson

On 12/25/2016 08:16 PM, Stefan Monnier wrote:
>>> I think we can skip the second tar with something like
>>> "tar -cvhf /dev/null 2>&1".
>> I tried this before, and again just now, but it does not cause make to
>> execute at a significantly different speed on my machine.  Is the effect
>> more noticeable on yours?
> 
> I haven't looked at the performance side of this.  It just seemed simpler.
> 
>> $ cd a
>> $ tar -ch *.el --no-recursion --exclude-vcs -X .elpaignore | tar --list
>>
>> The above command correctly yields "b.el".
>>
>> Did you have any other cases in mind?
> 
> No, I was rather wondering if this behavior is documented or just accidental.
> 
> 
>         Stefan
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Change-to-package-directory-before-checking-.elpaign.patch --]
[-- Type: text/x-patch; name="0001-Change-to-package-directory-before-checking-.elpaign.patch", Size: 1616 bytes --]

From e05054c3f9b6cf6ee0dbeafd0438b562f06afc64 Mon Sep 17 00:00:00 2001
From: Jackson Ray Hamilton <jackson@jacksonrayhamilton.com>
Date: Mon, 26 Dec 2016 11:25:21 -0800
Subject: [PATCH] Change to package directory before checking .elpaignore
 exclusions.

If we don't do this, the package's directory's name is included in the file
names that are checked for .elpaignore matches.  .elpaignore matches should be
assumed to occur inside the package's directory.
---
 GNUmakefile | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/GNUmakefile b/GNUmakefile
index 6d57fae..8edb2f8 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -150,13 +150,18 @@ $(foreach al, $(autoloads), $(eval $(call RULE-srcdeps, $(al))))
 included_els := $(shell \
   for pt in packages/*; do				\
       if [ -d $$pt ]; then				\
-          if [ -f "$${pt}/.elpaignore" ]; then		\
-              tar -ch $$pt/*.el --no-recursion		\
-                  --exclude-vcs -X "$${pt}/.elpaignore"	\
+          prev=$$(pwd);					\
+          cd $$pt;					\
+          if [ -f .elpaignore ]; then			\
+              tar -ch *.el --no-recursion		\
+                  --exclude-vcs -X .elpaignore		\
                 | tar --list;				\
           else						\
-              ls -1 $$pt/*.el;				\
-          fi;						\
+              ls -1 *.el;				\
+          fi | while read line; 			\
+                   do echo "$${pt}/$${line}"; 		\
+               done;					\
+          cd $$prev;					\
       fi;						\
   done)
 els := $(call FILTER-nonsrc, $(included_els))
-- 
2.1.4


  reply	other threads:[~2016-12-26 19:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20161223195027.29384.58430@vcs.savannah.gnu.org>
     [not found] ` <20161223195027.7C9E52201BC@vcs.savannah.gnu.org>
2016-12-23 23:49   ` [elpa] master 580a1b6: Respect .elpaignore when compiling and optimize compilation Stefan Monnier
2016-12-24  6:58     ` Jackson Ray Hamilton
2016-12-26  4:16       ` Stefan Monnier
2016-12-26 19:57         ` Jackson Ray Hamilton [this message]
2016-12-27  3:29           ` Stefan Monnier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=318da984-8e21-fece-3d61-2e3846a1cef6@jacksonrayhamilton.com \
    --to=jackson@jacksonrayhamilton.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).