[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake's .el support vs. recent loss of byte-compile-dest-file
From: |
Jim Meyering |
Subject: |
Re: automake's .el support vs. recent loss of byte-compile-dest-file |
Date: |
Tue, 28 Nov 2017 19:35:04 -0800 |
On Mon, Nov 27, 2017 at 8:36 AM, Eli Zaretskii <address@hidden> wrote:
>> From: Jim Meyering <address@hidden>
>> Date: Sun, 26 Nov 2017 17:17:59 -0800
>> Cc: emacs-devel <address@hidden>, Paul Eggert <address@hidden>
>>
>> >> I've just posted an automake fix:
>> >> https://lists.gnu.org/archive/html/automake/2017-11/msg00038.html
>> >
>> > Thanks. The question that's important to us is, of course, when will
>> > this fixed version be available widely enough for us to consider
>> > removing the support for the old ones.
>>
>> I agree. What Emacs does here will influence at least the wording of
>> the automake NEWS entry for that automake change I mentioned. Should I
>> call it a bug fix, because this behavior will make it into a release?
>> Or is it just a work-around for those who happen to be using
>> pre-release Emacs, and it won't affect anyone using an actual release?
>
> My intention, unless I hear objections, is to resurrect the removed
> feature on the emacs-26 branch, but add an annoying warning there, so
> that any packages and maintainers who didn't notice the deprecation
> will do so sooner rather than later. But the feature will remain
> removed on the master branch, which will eventually become Emacs 27.
> So I think your change is a bug fix, and its purpose is to make
> Automake future-proof against imminent changes in Emacs. It is also
> for those who already use development snapshots of Emacs 27, because
> the function will remain removed there.
Thanks.
Another possible fix proposed by Glenn was to use -l bytecomp and to
continue to override byte-compile-dest-file.
However, I have hit a new seemingly unrelated snag: subdirs. This now
fails, where the argument to byte-compile-file is a dot-relative name
in a subdirectory:
$ (export TMPDIR=/tmp; mkdir sub && : > sub/x.el && emacs --batch -l
bytecomp --eval '(defun byte-compile-dest-file (f) "sub/x.elc")'
--eval "(unless (byte-compile-file \"sub/x.el\") (kill-emacs 1))" )
Creating file with prefix: No such file or directory, /tmp/sub/x.elc
While it worked fine with emacs built from a commit on master from
2017-07-29, some time between then and Aug 11, things changed so that
byte-compiling such a source file name requires the relative directory
name first be created in $TMPDIR.
Was that deliberate?
For reference, this was exposed because an automake test exercises
that code path: I ran it individually via this: make check
TESTS='t/lisp-subdir.sh'
- automake's .el support vs. recent loss of byte-compile-dest-file, Jim Meyering, 2017/11/22
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Paul Eggert, 2017/11/22
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Jim Meyering, 2017/11/23
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Eli Zaretskii, 2017/11/23
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Jim Meyering, 2017/11/23
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Eli Zaretskii, 2017/11/23
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Jim Meyering, 2017/11/26
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Eli Zaretskii, 2017/11/27
- Re: automake's .el support vs. recent loss of byte-compile-dest-file,
Jim Meyering <=
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Paul Eggert, 2017/11/29
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Eli Zaretskii, 2017/11/29
- Re: automake's .el support vs. recent loss of byte-compile-dest-file, Jim Meyering, 2017/11/29