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

[Jim Meyering]

On Mon, Dec 11, 2017 at 11:03 AM, Jim Meyering <j...@meyering.net> wrote:
> On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris <r...@gnu.org> wrote:
>>
>> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):
>>
>>> However, I don't see how "-f batch-byte-compile" can be used when
>>> the .elc file must be created in a directory separate from the one
>>> containing the .el file.
>>
>> I meant, instead of reinventing the wheel with this part:
>>
>>  --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"
>>
>> Example:
>>
>> mkdir /tmp/foo /tmp/bar
>> echo '(message "hi")' > /tmp/foo/foo.el
>> emacs --batch \
>>  --eval '(setq byte-compile-dest-file-function (lambda (x) 
>> "/tmp/bar/foo.elc"))' \
>>  -f batch-byte-compile /tmp/foo/foo.el
>>
>> -> generates /tmp/bar/foo.elc
>>
>> batch-byte-compile exists since forever.
>
> Thank you. That looks better, indeed. I will see if I can adapt the
> automake patch accordingly.

I've done that and will push the attached to master later today.
Thanks,
Jim
From e56d637494d4e5c9f0cca0d6417b21d683eb7d6f Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
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.master 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.
The removed functionality has been restored for Emacs-26, albeit with
dissuasive diagnostics warning about the imminent removal of this
functionality.  It will be removed in Emacs-27.
* lib/am/lisp.am (.el.elc): Use byte-compile-dest-file-function, rather
than byte-compile-dest-file.  Also, use "-f batch-byte-compile '$<'"
rather than open-coding it, as suggested by Glenn Morris.
* 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|  6 +++---
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 4 files changed, 55 insertions(+), 3 deletions(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

diff --git a/NEWS b/NEWS
index 6d8b9d248..7d52aeb93 100644
--- a/NEWS
+++ b/NEWS
@@ -124,6 +124,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..91a0e0516 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -30,7 +30,7 @@ endif %?INSTALL%
 ## The destination file is normally determined by appending "c" to the
 ## input (which would erronously put it in $(srcdir) in VPATH builds),
 ## so we override that, too.
-   if test "$(EMACS)" != "no"; then \
+   if test '$(EMACS)' != no; then \
  am__dir=. am__subdir_includes=''; \
  case $@ in */*) \
am__dir=`echo '$@' | sed 's,/[^/]*$$,,'`; \
@@ -41,8 +41,8 @@ endif %?INSTALL%
  $(EMACS) --batch \
$(AM_ELCFLAGS) $(ELCFLAGS) \
$$am__subdir_includes -L $(builddir) -L $(srcdir) \
-   --eval "(defun byte-compile-dest-file (f) \"$@\")" \
-   --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"; \
+   --eval '(setq byte-compile-dest-file-function (lambda (_) "$@"))' \
+   -f batch-byte-compile '$<'; \
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

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

[Jim Meyering]

On Mon, Dec 11, 2017 at 9:56 AM, Glenn Morris  wrote:
>
> Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):
>
>> However, I don't see how "-f batch-byte-compile" can be used when
>> the .elc file must be created in a directory separate from the one
>> containing the .el file.
>
> I meant, instead of reinventing the wheel with this part:
>
>  --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"
>
> Example:
>
> mkdir /tmp/foo /tmp/bar
> echo '(message "hi")' > /tmp/foo/foo.el
> emacs --batch \
>  --eval '(setq byte-compile-dest-file-function (lambda (x) 
> "/tmp/bar/foo.elc"))' \
>  -f batch-byte-compile /tmp/foo/foo.el
>
> -> generates /tmp/bar/foo.elc
>
> batch-byte-compile exists since forever.

Thank you. That looks better, indeed. I will see if I can adapt the
automake patch accordingly.

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

[Glenn Morris]

Jim Meyering wrote (on Sun, 10 Dec 2017 at 17:01 -0800):

> However, I don't see how "-f batch-byte-compile" can be used when
> the .elc file must be created in a directory separate from the one
> containing the .el file.

I meant, instead of reinventing the wheel with this part:

 --eval "(unless (byte-compile-file \"$<\") (kill-emacs 1))"

Example:

mkdir /tmp/foo /tmp/bar
echo '(message "hi")' > /tmp/foo/foo.el
emacs --batch \
 --eval '(setq byte-compile-dest-file-function (lambda (x) 
"/tmp/bar/foo.elc"))' \
 -f batch-byte-compile /tmp/foo/foo.el 

-> generates /tmp/bar/foo.elc

batch-byte-compile exists since forever.

> I think automake generates code the way it does because GNU coding
> standards mandate that one be able to build from a read-only
> hierarchy of sources (think read-only media).

Again, not something Emacs itself supports for its own Lisp files.

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

[Jim Meyering]

On Wed, Nov 29, 2017 at 12:17 PM, Glenn Morris  wrote:
> The obsolete bytecomp feature is back as of Emacs 9964db4.

Thanks, I noticed when that was restored, but have been a way for a while.

> BTW, why doesn't lisp.am use the standard "-f batch-byte-compile"
> method of producing .elc files?
>
> Your two issues that affected only automake illustrate that the way
> automake generates .elc files is different to the vast majority of
> Emacs projects.

Thanks for the suggestion, Glenn. However, I don't see how "-f
batch-byte-compile" can be used when the .elc file must be created in
a directory separate from the one containing the .el file. I think
automake generates code the way it does because GNU coding standards
mandate that one be able to build from a read-only hierarchy of
sources (think read-only media).

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

[Glenn Morris]

The obsolete bytecomp feature is back as of Emacs 9964db4.

BTW, why doesn't lisp.am use the standard "-f batch-byte-compile"
method of producing .elc files?

Your two issues that affected only automake illustrate that the way
automake generates .elc files is different to the vast majority of
Emacs projects.

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

[Jim Meyering]

On Tue, Nov 28, 2017 at 2:23 PM, Glenn Morris  wrote:
> Jim Meyering wrote:
>
>> 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.
>
> Oh, so you only split .el and .elc up while building, but they get
> installed into the same place? That's not so bad, though it is, eg, not
> something that Emacs supports in its own build process (in non-srcdir
> builds, .elc still get written into srcdir).
>
> BTW:
>
> ELCFLAGS=-lbytecomp
>
> is presumably another way to solve your issue, for any version of Emacs
> and automake (once bytecomp is loaded you can redefine functions as you wish).

Thanks for the suggestion, Glenn.
However, I've hit a new snag: subdirs.
I posted details and a smaller stand-alone demonstrator on the
emacs-devel thread: TL;DR this automake test fails regardless:

   make check TESTS='t/lisp-subdir.sh'

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

[Glenn Morris]

Jim Meyering wrote:

> 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.

Oh, so you only split .el and .elc up while building, but they get
installed into the same place? That's not so bad, though it is, eg, not
something that Emacs supports in its own build process (in non-srcdir
builds, .elc still get written into srcdir).

BTW:

ELCFLAGS=-lbytecomp

is presumably another way to solve your issue, for any version of Emacs
and automake (once bytecomp is loaded you can redefine functions as you wish).

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

[Mathieu Lirzin]

Jim Meyering <j...@meyering.net> writes:

> On Mon, Nov 27, 2017 at 8:12 PM, Jim Meyering <j...@meyering.net> wrote:
>> On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering <j...@meyering.net> wrote:
>>> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> wrote:
>>>>
>>>> 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.

I don't like this idea neither.

> 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 <meyer...@fb.com>
> 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.

OK to push.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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 <j...@meyering.net> wrote:
> On Mon, Nov 27, 2017 at 12:52 PM, Jim Meyering <j...@meyering.net> wrote:
>> On Mon, Nov 27, 2017 at 10:27 AM, Glenn Morris <rgm+n...@gnu.org> 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 <meyer...@fb.com>
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.

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?

Re: Update HACKING (was: [PATCH] port elisp-compilation support to emacs-23.1 and newer)

[Jim Meyering]

On Fri, Nov 24, 2017 at 4:42 AM, Mathieu Lirzin  wrote:
> Mathieu Lirzin  writes:
>
>> Indeed HACKING is not up-to-date, I will fix that.
>
> Here is a patch that should help describing the new branching model more
> accurately.  If you see further improvements or would prefer different
> wording, tell me.

Thanks.
That looks fine.

By the way, I'm waiting to hear from Emacs folks to determine how to
word the NEWS entry for my master-destined elisp-compilation-fix
commit.

Update HACKING (was: [PATCH] port elisp-compilation support to emacs-23.1 and newer)

[Mathieu Lirzin]

Mathieu Lirzin  writes:

> Indeed HACKING is not up-to-date, I will fix that.

Here is a patch that should help describing the new branching model more
accurately.  If you see further improvements or would prefer different
wording, tell me.

>From 2e6c978a944eb57d49336b01a03dd6f9e573cd81 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Fri, 24 Nov 2017 13:28:24 +0100
Subject: [PATCH] maint: Update HACKING

* HACKING (Working with git): Remove reference to the 'micro' branch and
adapt branch descriptions to the current branching scheme.
---
 HACKING | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/HACKING b/HACKING
index 8e7764b..ded1c7f 100644
--- a/HACKING
+++ b/HACKING
@@ -156,15 +156,8 @@
   latest stable version of Autoconf installed and available early
   in your PATH.
 
-* The Automake git tree currently carries three basic branches: 'micro',
-  'maint' and 'master'.
-
-* The 'maint' branch, reserved to changes that should go into the next
-  micro release; so it will just see fixes for regressions, trivial
-  bugs, or documentation issues, and no "active" development whatsoever.
-  Since emergency regression-fixing or security releases could be cut
-  from this branch at any time, it should always be kept in a releasable
-  state.
+* The Automake git tree currently carries three basic branches: 'master',
+  'next' and 'maint'.
 
 * The 'master' branch is where the development of the next release
   takes place.  It should be kept in a stable, almost-releasable state,
@@ -172,6 +165,16 @@
   this is not a hard rule, and such "stability" is not expected to be
   absolute (emergency releases are cut from the 'maint' branch anyway).
 
+* When planning a release a dedicated branch should be created and after
+  the release is done, the release branch is to be merged both into the
+  'master' branch and the 'maint' branch.
+
+* Besides merges from release branches, the 'maint' branch can contain
+  fixes for regressions, trivial bugs, or documentation issues, that
+  will be part of an emergency regression-fixing or security releases.
+  As a consequence it should always be kept in a releasable state and no
+  "active" development should be done whatsoever.
+
 * The 'next' branch is reserved for the development of the next major
   release.  Experimenting a little is OK here, but don't let the branch
   grow too unstable; if you need to do exploratory programming or
@@ -187,15 +190,6 @@
   developments.  They should be based off of a common ancestor of all
   active branches to which the feature should or might be merged later.
 
-* After a release is done, the release branch is to be merged both
-  into the 'master' branch and the 'maint' branch.
-
-* When fixing a bug (especially a long-standing one), it may be useful
-  to commit the fix to a new temporary branch based off the commit that
-  introduced the bug.  Then this "bugfix branch" can be merged into all
-  the active branches descending from the buggy commit.  This offers a
-  simple way to fix the bug consistently and effectively.
-
 * When merging, prefer 'git merge --log' over plain 'git merge', so that
   a later 'git log' gives an indication of which actual patches were
   merged even when they don't appear early in the list.
-- 
2.9.5


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Mathieu Lirzin]

Jim Meyering  writes:

> On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin  wrote:
>>
>> Jim Meyering  writes:
>>
>>> Pushed to the micro branch:
>>>
>>> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39
>>
>> With the "recent" change in Automake branch naming scheme, 'master'
>> seems a better fit for this:
>>
>>   https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html
>>
>> Thanks.
>
> Hi Mathieu,
> Happy to adjust. Would you prefer that I merge micro into master,
> then... or something else? Then delete micro? When I noticed that I'd
> created that branch (after reading the description in HACKING), I
> figured I'd missed something.

Indeed HACKING is not up-to-date, I will fix that.

Cherry-picking the commit and deleting 'micro' would be nice.  Moreover
I think it worths adding a NEWS entry for this bug fix, if you agree
please add it.  :-)

The fix will be released in 1.16.  I was planning to make this release
by the end of the year, but given that I am quite busy at the university
I think i won't be able to make it before January/February.

Thanks for fixing this issue.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Jim Meyering]

On Thu, Nov 23, 2017 at 3:57 PM, Mathieu Lirzin <m...@gnu.org> wrote:
> Hello Jim,
>
> Jim Meyering <j...@meyering.net> writes:
>
>> On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote:
>>> I wanted to make a new idutils release, but was blocked because
>>> its "make distcheck" would fail. That was because it distributes
>>> and builds from an elisp file, and automake's elisp-compilation
>>> rule uses a function that was marked obsolete back in 2009.
>>> Upstream Emacs finally removed support for that function in May,
>>> so anyone using emacs built since then will see the same failure
>>> I saw. It also strikes whenever building from a read-only source
>>> directory.
>>>
>>> This change switches the build command to use the "new" way.
>>>
>>> I started discussion on emacs-devel last night:
>>> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>>>
>>>
>>> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
>>> From: Jim Meyering <meyer...@fb.com>
>>> 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, 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.
>>> * 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.
>>
>> Pushed to the micro branch:
>>
>> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39
>
> With the "recent" change in Automake branch naming scheme, 'master'
> seems a better fit for this:
>
>   https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html
>
> Thanks.

Hi Mathieu,
Happy to adjust. Would you prefer that I merge micro into master,
then... or something else? Then delete micro? When I noticed that I'd
created that branch (after reading the description in HACKING), I
figured I'd missed something.

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

[Mathieu Lirzin]

Hello Jim,

Jim Meyering <j...@meyering.net> writes:

> On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote:
>> I wanted to make a new idutils release, but was blocked because
>> its "make distcheck" would fail. That was because it distributes
>> and builds from an elisp file, and automake's elisp-compilation
>> rule uses a function that was marked obsolete back in 2009.
>> Upstream Emacs finally removed support for that function in May,
>> so anyone using emacs built since then will see the same failure
>> I saw. It also strikes whenever building from a read-only source
>> directory.
>>
>> This change switches the build command to use the "new" way.
>>
>> I started discussion on emacs-devel last night:
>> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>>
>>
>> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
>> From: Jim Meyering <meyer...@fb.com>
>> 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, 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.
>> * 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.
>
> Pushed to the micro branch:
>
> https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39

With the "recent" change in Automake branch naming scheme, 'master'
seems a better fit for this:

  https://lists.gnu.org/archive/html/bug-automake/2017-09/msg00015.html

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

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

[Jim Meyering]

On Thu, Nov 23, 2017 at 7:38 AM, Jim Meyering <j...@meyering.net> wrote:
> I wanted to make a new idutils release, but was blocked because
> its "make distcheck" would fail. That was because it distributes
> and builds from an elisp file, and automake's elisp-compilation
> rule uses a function that was marked obsolete back in 2009.
> Upstream Emacs finally removed support for that function in May,
> so anyone using emacs built since then will see the same failure
> I saw. It also strikes whenever building from a read-only source
> directory.
>
> This change switches the build command to use the "new" way.
>
> I started discussion on emacs-devel last night:
> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html
>
>
> From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyer...@fb.com>
> 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, 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.
> * 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.

Pushed to the micro branch:

https://git.savannah.gnu.org/cgit/automake.git/commit/?h=micro=9182df7e4810a411147d523de8cd141e749c5e39

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

[Jim Meyering]

I wanted to make a new idutils release, but was blocked because
its "make distcheck" would fail. That was because it distributes
and builds from an elisp file, and automake's elisp-compilation
rule uses a function that was marked obsolete back in 2009.
Upstream Emacs finally removed support for that function in May,
so anyone using emacs built since then will see the same failure
I saw. It also strikes whenever building from a read-only source
directory.

This change switches the build command to use the "new" way.

I started discussion on emacs-devel last night:
https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00551.html


>From ecad5844100d5193ecd58f66f31f6bbf0ef04e23 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@fb.com>
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, 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.
* 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.
---
 lib/am/lisp.am|  2 +-
 t/lisp-readonly-srcdir.sh | 46 ++
 t/list-of-tests.mk|  1 +
 3 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 t/lisp-readonly-srcdir.sh

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 <https://www.gnu.org/licenses/>.
+
+# Ensure that building elisp from a read-only srcdir works.
+
+required=emacs
+. test-init.sh
+
+cat > Makefile.am << 'EOF'
+lisp_LISP = am-one.el
+EOF
+
+cat >> configure.ac << 'EOF'
+AM_PATH_LISPDIR
+AC_OUTPUT
+EOF
+
+echo > am-one.el
+
+$ACLOCAL
+$AUTOCONF
+$AUTOMAKE --add-missing
+
+mkdir sub
+chmod a=rx .
+
+cd sub
+../configure
+$MAKE
+
+test -f am-one.elc
+
+:
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d234aef48..3dab63d32 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -656,6 +656,7 @@ t/lisp5.sh \
 t/lisp6.sh \
 t/lisp7.sh \
 t/lisp8.sh \
+t/lisp-readonly-srcdir.sh \
 t/lisp-loadpath.sh \
 t/lisp-subdir.sh \
 t/lisp-subdir2.sh \
--
2.14.1.729.g59c0ea183