Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Nov 27, 2017 at 8:12 PM, Jim Meyering  wrote:
> On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering  wrote:
>> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris  wrote:
>>> Jim Meyering wrote:
>>>
 In May of 2017, support for using the long-deprecated
 byte-compile-dest-file function was removed, and that removal broke
 automake's elisp-compiling rule for any .el file not in the current
 directory.
>>>
>>> In general, Emacs expects .el and .elc to be found in the same
>>> directory. Not adhering to this convention will likely break various
>>> Emacs features. Is this really something automake needs to enable at all?
>>
>> An alternative would be to copy-or-link the .el file into the
>> destination directory. Indeed. That would work without breaking pre-23
>> emacs, so I will adjust my automake patch before pushing it to master.
>
> Hi Glenn,
>
> I've thought about this some more and do not like the idea of
> requiring automake's elisp-compilation rule to make a copy of the
> source file in the destination directory in this slightly contrived
> case. Remember: this arises only in a non-srcdir build. That means
> build artifacts end up being written into the mostly-empty current
> directory hierarchy, which does not have copies of the sources.
> Installation processes will continue to copy both .el and .elc files
> into place.

Here is the updated (NEWS addition) patch that I expect to push to
master tomorrow. Feedback welcome. I will also delete the "micro"
branch I created.
From 7558bddcc9cf5ee14441304c2cfc7cffb566daba Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Wed, 22 Nov 2017 21:07:29 -0800
Subject: [PATCH] port elisp-compilation support to emacs-23.1 and newer

In May of 2017, Emacs' support for using the long-deprecated
byte-compile-dest-file function was removed, and that removal broke
automake's elisp-compiling rule for any .el file not in the current
directory.  In emacs-23.1 (July 2009) byte-compile-dest-file-function
became the recommended way to adjust the byte-compiler's destination.
We expect the removed functionality to be restored for Emacs-26,
albeit with dissuasive diagnostics warning about the imminent removal
of this functionality.  It may be removed in Emacs-27.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function,
rather than byte-compile-dest-file.
* t/lisp-readonly-srcdir.sh: New file, to test for the above.
* t/list-of-tests.mk (handwritten_TESTS): Add it.
* NEWS (Bugs fixed): Mention this problem.
---
 NEWS  |  5 +
 lib/am/lisp.am|  2 +-
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/NEWS b/NEWS
index 04a285565..dd057b7b1 100644
--- a/NEWS
+++ b/NEWS
@@ -121,6 +121,11 @@ New in ?.?.?:
   - The time printed by 'mdate-sh' is now using the UTC time zone to support
 the reproducible build effort.  (automake bug#20314)

+  - The elisp byte-compilation rule now uses byte-compile-dest-file-function,
+rather than byte-compile-dest-file, which was obsoleted in 2009. We expect
+that Emacs-26 will continue to support the old function, but will complain
+loudly, and that Emacs-27 will remove support for it altogether.
+
 

 New in 1.15.1:
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 881bf3457..cacbc6feb 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -41,7 +41,7 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
+   --eval "(setq byte-compile-dest-file-function (lambda (_) \"$@\"))" 
\
--eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
else :; fi

diff --git a/t/lisp-readonly-srcdir.sh b/t/lisp-readonly-srcdir.sh
new file mode 100644
index 0..38b866404
--- /dev/null
+++ b/t/lisp-readonly-srcdir.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2017 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+# Ensure that building elisp from a read-only srcdir works.
+

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering  wrote:
> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris  wrote:
>> Jim Meyering wrote:
>>
>>> In May of 2017, support for using the long-deprecated
>>> byte-compile-dest-file function was removed, and that removal broke
>>> automake's elisp-compiling rule for any .el file not in the current
>>> directory.
>>
>> In general, Emacs expects .el and .elc to be found in the same
>> directory. Not adhering to this convention will likely break various
>> Emacs features. Is this really something automake needs to enable at all?
>
> An alternative would be to copy-or-link the .el file into the
> destination directory. Indeed. That would work without breaking pre-23
> emacs, so I will adjust my automake patch before pushing it to master.

Hi Glenn,

I've thought about this some more and do not like the idea of
requiring automake's elisp-compilation rule to make a copy of the
source file in the destination directory in this slightly contrived
case. Remember: this arises only in a non-srcdir build. That means
build artifacts end up being written into the mostly-empty current
directory hierarchy, which does not have copies of the sources.
Installation processes will continue to copy both .el and .elc files
into place.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Jim Meyering]

On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris  wrote:
> Jim Meyering wrote:
>
>> In May of 2017, support for using the long-deprecated
>> byte-compile-dest-file function was removed, and that removal broke
>> automake's elisp-compiling rule for any .el file not in the current
>> directory.
>
> In general, Emacs expects .el and .elc to be found in the same
> directory. Not adhering to this convention will likely break various
> Emacs features. Is this really something automake needs to enable at all?

An alternative would be to copy-or-link the .el file into the
destination directory. Indeed. That would work without breaking pre-23
emacs, so I will adjust my automake patch before pushing it to master.

Thanks.

However, please do consider undoing that breaking change before the
next emacs release, so we have a chance to release a fixed version of
automake before you remove the functionality being used in all
existing Makefile.in files.

Re: [PATCH] port elisp-compilation support to emacs-23.1 and newer

[Glenn Morris]

Jim Meyering wrote:

> In May of 2017, support for using the long-deprecated
> byte-compile-dest-file function was removed, and that removal broke
> automake's elisp-compiling rule for any .el file not in the current
> directory. 

In general, Emacs expects .el and .elc to be found in the same
directory. Not adhering to this convention will likely break various
Emacs features. Is this really something automake needs to enable at all?