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

[Andrea Corallo]

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: Thu, 10 Feb 2022 18:34:22 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> PS I tried to merge emacs-28 into master using gitmerge.el as suggested
>> >> in git-workflow as I suspected a conflict there that I wanted to solve
>> >> myself, but it says "nothing to merge".  Not sure if I'm doing something
>> >> wrong.
>> >
>> > I merged that change, but for the future: what exactly did you do, and
>> > in particular did you remember to switch to the master branch and do a
>> > "git pull" in master, before invoking "gitmerge"?
>> 
>> I did what's described in git-workflow, so yes I had master checked out
>> and I pulled before trying.  The only difference is that haven't started
>> a fresh emacs but loaded gitmerge.el in my current session.  Next time
>> I'll try with a fresh session and maybe with -Q.
>
> What was the default-directory when you invoked "M-x gitmerge"?  It
> should be the Emacs repository, and Emacs should know that the current
> branch in that directory is "master".

Okay thanks next time I'll verify that as well.

> Starting a new Emacs session is indeed better.  (I also have separate
> directories for master and the release branch, so for me changing the
> default-directory ("M-x cd") also means I'm sure gitmerge will use the
> correct branch.)
>
>> 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.

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.

Best Regards

  Andrea