bug#20867: 24.5; Change behavior of `batch-byte-compile' for directory arguments

bug#20867: 24.5; Change behavior of `batch-byte-compile' for directory arguments

[Philipp Stephani]

The behavior of `batch-byte-compile' differs between file name and
directory arguments: For file name arguments, compilation happens if
NOFORCE is not set, if the destination file doesn't exist, or if it is
older than the source file.  For directories, however, compilations
happens if the destination file already exists *and* it is older than
the source file; NOFORCE is ignored.  This behavior is not documented,
and I find it quite unintuitive.  Please change the behavior for
directories to match the behavior for files.



In GNU Emacs 24.5.1 (x86_64-apple-darwin14.1.0, NS apple-appkit-1344.72)
 of 2015-04-12 on p
Windowing system distributor `Apple', version 10.3.1347
Configured using:
 `configure --prefix=/usr/local/Cellar/emacs/24.5
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs/24.5/share/info/emacs
 --with-file-notification=gfile --with-dbus --with-gnutls --with-rsvg
 --with-imagemagick --without-popmail --with-ns
 --disable-ns-self-contained'

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify cocoa ns multi-tty emacs)

Memory information:
((conses 16 72026 5248)
 (symbols 48 17540 0)
 (miscs 40 36 128)
 (strings 32 9865 4736)
 (string-bytes 1 263432)
 (vectors 16 9022)
 (vector-slots 8 377079 14438)
 (floats 8 55 147)
 (intervals 56 184 0)
 (buffers 960 11))

bug#20867: 24.5; Change behavior of `batch-byte-compile' for directory arguments

[Lars Ingebrigtsen]

Philipp Stephani <p.stephani2@gmail.com> writes:

> The behavior of `batch-byte-compile' differs between file name and
> directory arguments: For file name arguments, compilation happens if
> NOFORCE is not set, if the destination file doesn't exist, or if it is
> older than the source file.  For directories, however, compilations
> happens if the destination file already exists *and* it is older than
> the source file; NOFORCE is ignored.  This behavior is not documented,
> and I find it quite unintuitive.  Please change the behavior for
> directories to match the behavior for files.

Yes, that's pretty odd behaviour, but I don't think it makes sense to
change it now -- it's been like this for decades.

Instead I've now just explained what it does in the doc string in Emacs
27.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no