emacs-devel
[Top][All Lists]
Advanced

[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'



reply via email to

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