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

[Corwin Brust]

On Sat, Feb 5, 2022 at 3:11 PM H. Dieter Wilhelm
<dieter@duenenhof-wilhelm.de> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> >> Cc: akrl@sdf.org,  corwin@bru.st,  drew.adams@oracle.com,  
> >> emacs-devel@gnu.org
> >> Date: Sat, 05 Feb 2022 20:25:17 +0100
> >>
> >> > I cannot reproduce this.  How exactly did you load strings.elc?
> >>
> >> M-x load-file
> >>
> >> with (load-file "d:/tmp/Corwin/strings.elc") it isn't working either on
> >> my machine!?
> >
> > Because you loaded a .elc file, explicitly.  Try this instead:
> >
> >   M-x load-library RET d:/tmp/Corwin/strings RET
>
> Indeed!

Awesome, thanks for this confirmation.  I think we now have a good
sense of where things stand with this report. I'll summarize things
(especially for Drew's benefit) in a new message, back up-thread.
First I'm planning to try building emacs-28 with the patch Eli
suggested, in case I might be able to provide feedback in advance of
when Andreas can look.

>
> [Nitpicking:] Would you consider it an omission that load-library is
> triggering a compilation but (load-file ".elc") not?  (No, probably not
> because load-file would need to consider files which are not directly
> submitted.)
>

IMO, no.  It's a feature:  when we specify an extension we get exactly
what we ask for, when we specify without any extension we get the
default behavior of favoring the most compiled version available,
creating the ELN if we can when we have an ELC but no ELN.