emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : emacs-28 windows binaries available from alpha


From: Andrea Corallo
Subject: Re: [External] : emacs-28 windows binaries available from alpha
Date: Fri, 11 Feb 2022 14:16:37 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> Date: Fri, 11 Feb 2022 09:21:52 +0000
>> 
>> Andrea Corallo <akrl@sdf.org> writes:
>> 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> [...]
>> 
>> >>> Anyway I was thinking if it wouldn't be correct to emit also a warning
>> >>> if libgccjit is not available.  This condition could prevent some
>> >>> package to work as expected (ex evil-mode IIRC) so might be worth to
>> >>> inform the user that and emacs compiled with native-comp is being run
>> >>> without libgccjit being available.
>> >>
>> >> I'm not sure I see the usefulness of such a warning.  If Emacs works
>> >> correctly regardless, the warning could annoy.  So I tend to think we
>> >> should introduce the warning only if enough users complain that Emacs
>> >> silently does something they'd prefer to know about.
>> >
>> > I think it might be useful for two reasons:
>> >
>> > 1- let the user know that a native compiled Emacs is being run without
>> >    access to libgccjit, not only it might not function as expected but
>> >    most likely I guess that if the user compiled a native compiled Emacs
>> >    he wants to have it working with native code.  So in general I guess
>> >    it might be informative.
>> >
>> > 2- help us identifying the issue when a bug is opened because of it, if
>> >    we suspect that's the problem we can ask the user to have a look to
>> >    the warnings.
>> >
>> > But indeed I'm not sure it's worth of so I asked.
>> >
>> > An alternative to point two would be having a trace of this in M-x
>> > report-emacs-bug.
>> 
>> Thinking about I think this might be a good idea anyway.
>
> I agree.  Would you mind proposing a patch?

Sure, something like:

>From ffa9772fa5b04f916d6b49668dbd93b1743f6c18 Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@sdf.org>
Date: Fri, 11 Feb 2022 15:00:57 +0100
Subject: [PATCH] * lisp/mail/emacsbug.el (report-emacs-bug): Report libgccjit
 status.

---
 lisp/mail/emacsbug.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index f5559e39f6..759d8c11b5 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -304,6 +304,9 @@ report-emacs-bug
     (emacs-bug--system-description)
     (insert "Configured features:\n" system-configuration-features "\n\n")
     (fill-region (line-beginning-position -1) (point))
+    (when (and (featurep 'native-compile)
+               (null (native-comp-available-p)))
+      (insert "NATIVE_COMP present but libgccjit not available\n\n"))
     (insert "Important settings:\n")
     (mapc
      (lambda (var)
-- 
2.20.1

The output (if necessary) is placed after NATIVE_COMP feature is
mentioned, ex:

====================

Configured using:
 'configure --without-x --with-native-compilation'

Configured features:
DBUS GMP GNUTLS LIBSELINUX MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
SECCOMP SOUND THREADS XIM ZLIB

NATIVE_COMP present but libgccjit not available

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

====================

Not sure if we like to place it elsewhere and/or if we have a better
message to be displayed.

Thanks

  Andrea

reply via email to

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