GNU bug report logs - #58025
[PATCH] Ensure `byte-compile-dest-file-function' is used

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58025 in the body.
You can then email your comments to 58025 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: emacs <at> unbit.co.uk
To: bug-automake <at> gnu.org
Subject: [PATCH] Ensure `byte-compile-dest-file-function' is used
Date: Fri, 23 Sep 2022 13:24:24 +0100

[Message part 1 (text/plain, inline)]

The attached `git format-patch` is based on automake v1.16.5 and fixes
the following warning

    Warning (bytecomp): byte-compile-dest-file is obsolete (as of 23.2);
    Set byte-compile-dest-file-function instead.

The solution is to ensure bytecomp is loaded which defines
byte-compile-dest-file-function so it can be used when available,
and fallback to the original byte-compile-dest-file for earlier
GNU Emacs and XEmacs.

So far I've tested the result on

* CentOS 7.9 (distro emacs 24.3)
* OpenBSD 7.1 (custom emacs 28.2)
* OpenSUSE Leap 15.4 (distro emacs 27.2, xemacs 21.5)

and the warning is no longer generated.

[0001-Ensure-byte-compile-dest-file-function-is-used-when-.patch (text/x-diff, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: bug-automake <at> gnu.org, emacs <at> unbit.co.uk
Subject: Re: bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is
 used
Date: Fri, 23 Sep 2022 11:15:57 -0400

On Fri, Sep 23, 2022, at 8:24 AM, emacs <at> unbit.co.uk wrote:
> The attached `git format-patch` is based on automake v1.16.5 and fixes
> the following warning
>
>      Warning (bytecomp): byte-compile-dest-file is obsolete (as of 23.2);
>      Set byte-compile-dest-file-function instead.
>
> The solution is to ensure bytecomp is loaded which defines
> byte-compile-dest-file-function so it can be used when available,
> and fallback to the original byte-compile-dest-file for earlier
> GNU Emacs and XEmacs.
>
> So far I've tested the result on
>
> * CentOS 7.9 (distro emacs 24.3)
> * OpenBSD 7.1 (custom emacs 28.2)
> * OpenSUSE Leap 15.4 (distro emacs 27.2, xemacs 21.5)

Thank you for the patch.  Are you able to test it with a version of GNU Emacs older than 23.2?  I see that you tested it with XEmacs 21, but as I recall there were quite substantial differences between XEmacs 21 and GNU Emacs of similar vintage.

In addition, if you are able to do the archaeology to report *when bytecomp.el was added to Emacs*, i.e. how far back you have to go before `emacs -l bytecomp` will fail, that would be helpful.  I'm betting it's well before the oldest version we care about, given that bytecomp.el (in 27.1) lists its oldest copyright year as 1985 and <jwz <at> lucid.com> as the original author, but I'd still like to know for sure.

zw

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Hopkins <emacs <at> unbit.co.uk>
To: Zack Weinberg <zack <at> owlfolio.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is
 used
Date: Fri, 23 Sep 2022 19:11:18 +0100

On 2022-09-23 16:15, Zack Weinberg wrote:
> 
> Thank you for the patch.  Are you able to test it with a version of
> GNU Emacs older than 23.2?  I see that you tested it with XEmacs 21,
> but as I recall there were quite substantial differences between
> XEmacs 21 and GNU Emacs of similar vintage.

Not yet, I'm trying to obtain access but don't know if I can.

> 
> In addition, if you are able to do the archaeology to report *when
> bytecomp.el was added to Emacs*, i.e. how far back you have to go
> before `emacs -l bytecomp` will fail, that would be helpful.  I'm
> betting it's well before the oldest version we care about, given that
> bytecomp.el (in 27.1) lists its oldest copyright year as 1985 and
> <jwz <at> lucid.com> as the original author, but I'd still like to know for
> sure.
> 

The Emacs git repository doesn't have tags for all releases, but these
two are the most relevant for now: 18.59 (1992-10-30) and 19.34 
(1996-08-21).

The ability to load bytecomp.el and use `batch-byte-compile' has been
present since at least 18.59 with (lisp/bytecomp.el), and still
available in 19.34 via lisp/emacs-lisp/bytecomp.el.  It should have
been present in earlier versions too as it's in NEWS.1-17.

However, it looks like only 19.34 onwards supports
`byte-compile-dest-file' which automake falls back to for the output
.elc; 18.59 just appends a "c" to the source file (see
`byte-recompile-directory'). The newer and preferred
`byte-compile-dest-file-function' came in 23.2 (2010-05-08).

So it looks like this patch is ok to load bytecomp, as that is where
both `batch-byte-compile' and `byte-compile-dest-file' comes from in
early GNU Emacs and XEmacs, along with
`byte-compile-dest-file-function' for later GNU Emacs.

Any thoughts?

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Hopkins <emacs <at> unbit.co.uk>
To: Zack Weinberg <zack <at> owlfolio.org>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is
 used
Date: Sat, 24 Sep 2022 10:45:02 +0100

On 2022-09-23 16:15, Zack Weinberg wrote:
> Thank you for the patch.  Are you able to test it with a version of
> GNU Emacs older than 23.2?  I see that you tested it with XEmacs 21,
> but as I recall there were quite substantial differences between
> XEmacs 21 and GNU Emacs of similar vintage.
> 

I've now managed to test this on Emacs 21.4.1 (Slackware 12.0) and
the byte compilation works - loading bytecomp is fine, and
`byte-compile-dest-file' is defined as expected.  The other patch
to respect silent rules also works on 21.4.1.

If we do need to support that far back I will investigate the "-Q"
/ "--no-site-file" handling to improve compatibility across the
board.

"-Q" will error before GNU Emacs 22, and is ignored on XEmacs.

"-no-site-file" (single hypen) should be used instead of
"--no-site-file" as it works on all of them.

"-Q" also shouldn't be specified on later GNU Emacs as it affects
the result of `am_cv_lispdir' calculation due to excluding
site lisp directories from `load-path' which it's trying to find.
This is because "-Q" also adds "--no-site-lisp" in later GNU Emacs.

So, the plan will be to not use "-Q" and to use "-q -no-site-file"
instead.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Zack Weinberg" <zack <at> owlfolio.org>
To: bug-automake <at> gnu.org
Subject: Re: bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is
 used
Date: Mon, 26 Sep 2022 09:38:58 -0400

On Sat, Sep 24, 2022, at 5:45 AM, Richard Hopkins wrote:
> On 2022-09-23 16:15, Zack Weinberg wrote:
>> Thank you for the patch.  Are you able to test it with a version of
>> GNU Emacs older than 23.2?  I see that you tested it with XEmacs 21,
>> but as I recall there were quite substantial differences between
>> XEmacs 21 and GNU Emacs of similar vintage.
>
> I've now managed to test this on Emacs 21.4.1 (Slackware 12.0) and
> the byte compilation works - loading bytecomp is fine, and
> `byte-compile-dest-file' is defined as expected.  The other patch
> to respect silent rules also works on 21.4.1.
>
> If we do need to support that far back I will investigate the "-Q"
> / "--no-site-file" handling to improve compatibility across the
> board.

I'm not an official maintainer for Automake, but I think we probably
don't have to worry about Emacs any older than v21.  Would anyone
else like to express an opinion?

> "-Q" will error before GNU Emacs 22, and is ignored on XEmacs.
>
> "-no-site-file" (single hypen) should be used instead of
> "--no-site-file" as it works on all of them.
>
> "-Q" also shouldn't be specified on later GNU Emacs as it affects
> the result of `am_cv_lispdir' calculation due to excluding
> site lisp directories from `load-path' which it's trying to find.
> This is because "-Q" also adds "--no-site-lisp" in later GNU Emacs.
>
> So, the plan will be to not use "-Q" and to use "-q -no-site-file"
> instead.

This sounds like it would be a worthwhile change regardless of where
we decide to draw the line on supporting old versions of Emacs.

zw

Message #22 received at 58025-done <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: emacs <at> unbit.co.uk
Cc: 58025 <at> debbugs.gnu.org
Subject: Re: bug#58025: [PATCH] Ensure `byte-compile-dest-file-function' is
 used
Date: Mon, 26 Sep 2022 10:15:48 -0600

[Message part 1 (text/plain, inline)]

Hi Richard - I installed the -l bytecomp patch you sent (copied below).
It seems safe, and good in any case. Thanks.

If there are changes to make in the -Q / -q area, let's address those
separately. (I'll close this bug, I guess, but fine to keep discussing
wherever.) I don't think Automake uses -Q now?

Since the release of 1.16.5, there has been one change already, to pass
--no-site-file (as you can see below; I'll attach the current lisp.am
for possible convenience). From your research, I guess that should be
changed to -no-site-file (one hyphen)? Where is it that the
double-hyphen --no... fails?

In general, it is definitely necessary to support Emacs 21 (I use it :).
I'm not sure if we absolutely have to support 18 or 19, but when
possible, it is certainly desirable. --thanks, karl.


* lib/am/lisp.am (.el.elc): Require the bytecomp library so
byte-compile-dest-file-function can be used when available.
diff --git a/lib/am/lisp.am b/lib/am/lisp.am
index 6395ef389..500e2c530 100644
--- a/lib/am/lisp.am
+++ b/lib/am/lisp.am
@@ -41,6 +41,7 @@ endif %?INSTALL%
          $(EMACS) --batch --no-site-file \
            $(AM_ELCFLAGS) $(ELCFLAGS) \
            $$am__subdir_includes -L $(builddir) -L $(srcdir) \
+	    -l bytecomp \
            --eval '$(am__emacs_byte_compile_setup)' \
            -f batch-byte-compile '$<'; \
        else :; fi

[lisp.am (application/octet-stream, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.