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

[Jim Meyering]

Hello,

In May, this happened:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=233cfb0ea93ecdd2b63298be4243059e2e7a91fd

  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:

  https://git.savannah.gnu.org/cgit/automake.git/tree/lib/am/lisp.am#n44

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?

Thanks,
Jim