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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
> Date: Fri, 11 Feb 2022 09:16:25 +0000
> 
> >> 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.

This is unlikely to happen if the user has libgccjit installed: if it
is found when building Emacs, it will most probably be also found when
running it.

So the warning will mostly show when the user installed Emacs built by
someone else.  In which case, the user already made the decision not
to install libgccjit, so warning the user about that would be in
many/most cases redundant.

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

This could be a valuable indication, but if so, I think it's
report-emacs-bug that should detect and report it, as part of the
system configuration description, as you suggest.

> Another alternative to the problem on MS-Windows would be not to
> optimize calls to primitive functions and have them go always through
> funcall.  This is very easy compiler wise but has probably too drastic
> as brings a performance penalty.

Right.