Re: [Emacs-diffs] trunk r117152: Arrange to never byte-compile the generated -pkg.el file.

Re: [Emacs-diffs] trunk r117152: Arrange to never byte-compile the generated -pkg.el file.

[Stefan Monnier]

> +        ";;; -*- no-byte-compile: t -*-\n"

Sadly that doesn't help for the packages downloaded as tarballs which
already come with their own foo-pkg.el.  We really should instead call
`byte-recompile-directory' telling it to skip the foo-pkg.el.


        Stefan

Re: [Emacs-diffs] trunk r117152: Arrange to never byte-compile the generated -pkg.el file.

[Thien-Thi Nguyen]

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

() Stefan Monnier <monnier@iro.umontreal.ca>
() Sun, 25 May 2014 16:29:32 -0400

   Sadly that doesn't help for the packages downloaded as tarballs
   which already come with their own foo-pkg.el.  We really should
   instead call `byte-recompile-directory' telling it to skip the
   foo-pkg.el.

I see the ‘byte-recompile-directory’ guard expression:

     ;; It is an ordinary file.  Decide whether to compile it.
     (if (and (string-match emacs-lisp-file-regexp source)
              ;; The next 2 tests avoid compiling lock files
              (file-readable-p source)
              (not (string-match "\\`\\.#" file))
              (not (auto-save-file-name-p source))
              (not (string-equal dir-locals-file
                                 (file-name-nondirectory source))))
       ;; do it
       )

affords us only ‘auto-save-file-name-p’ and ‘dir-locals-file’ as
possible ways to exclude -pkg.el files, the latter probably a bit
easier since it's a variable, w/o modifying the filesystem.  If
modifying the filesystem is OK, i suppose another way is to make
the file temporarily unreadable around the
‘byte-recompile-directory’ call.

All of these strike me as inelegant.  Maybe now is good time to
address another issue of ‘byte-recompile-directory’, namely that
caller has no control over the order of the files processed.  As
author of ELPA package ‘xpm’, i would like this control and would
be willing to work a bit (i.e., manually specifying the desired
order) to get it.  I imagine others might desire similarly.

Support for explicit ordering (and thus, inclusion) in package.el
naturally lends itself to support for -pkg.el (or other
user-specified globbing / wildcards, for example) exclusion, a
nice (non-)coincidence, no?

Would such redesign be compatible w/ the package.el vision?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Emacs-diffs] trunk r117152: Arrange to never byte-compile the generated -pkg.el file.

[Stefan Monnier]

> affords us only ‘auto-save-file-name-p’ and ‘dir-locals-file’ as
> possible ways to exclude -pkg.el files, the latter probably a bit
> easier since it's a variable, w/o modifying the filesystem.

Indeed, the reason why *-pkg.el is currently recompiled is that the fix
wasn't as simple as let-binding a variable telling
byte-recompile-directory to ignore that file.

This said, it should be fairly easy to add a variable
(e.g. `byte-compile-ignored-files') for that purpose.

> If modifying the filesystem is OK,

Yuck!

> All of these strike me as inelegant.  Maybe now is good time to
> address another issue of ‘byte-recompile-directory’, namely that
> caller has no control over the order of the files processed.  As
> author of ELPA package ‘xpm’, i would like this control and would
> be willing to work a bit (i.e., manually specifying the desired
> order) to get it.  I imagine others might desire similarly.

I think this is ill-advised.  AFAIK the only kind of dependency that
might deserve such a treatment is the one where foo.el is newer than
foo.elc and where byte-compiling bar.el should not use the older
foo.elc.  But in the case of package.el there are no old elc files to
avoid, so there's no need for dependencies.

If you have another example where you think ordering of compilation
matters, feel free to post it, so I can try to shoot it down ;-)


        Stefan