[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

automake's .el support vs. recent loss of byte-compile-dest-file

From: Jim Meyering
Subject: automake's .el support vs. recent loss of byte-compile-dest-file
Date: Wed, 22 Nov 2017 20:41:46 -0800


In May, this happened:


  commit 233cfb0ea93ecdd2b63298be4243059e2e7a91fd
  Author: Glenn Morris <address@hidden>
  Date:   Sat May 6 18:01:34 2017 -0700

      Remove obsolete method of changing byte-compile-dest-file

      * lisp/emacs-lisp/bytecomp.el (byte-compile-dest-file):
      Define unconditionally.

That broke automake's .el.elc rule, as used in any automake-using
project that distributes an .el file. I noticed this because I want to
make a new release of GNU idutils (which distributes idutils.el). With
emacs built from that commit or newer, "make distcheck" now fails,
because the source is in a read-only directory, and the rule's attempt
to tell the byte-compiler to put the output in the current (writable)
directory is ignored. Hence the write fails, and "make distcheck" fails.

As for the automake-emitted rule, here's the code:


I can make it work with this automake change:

-           --eval "(defun byte-compile-dest-file (f) \"address@hidden")" \
+           --eval "(setq byte-compile-dest-file-function (lambda (_) 
\"address@hidden"))" \

But that will fail for those lacking byte-compile-dest-file-function,
which was introduced in 23.1 (2009).

Do you think it's worth supporting pre-23 emacs? If so, what's the best
way to make it work both before and after that May change?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]