Re: Native compilation on Windows, was Re: Bootstrap Compilation Speed

["H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>]

Corwin Brust <corwin@bru.st> writes:
> Thanks so much for testing Dieter!

Pleasure :-)

> On Sun, Jan 23, 2022 at 3:16 PM H. Dieter Wilhelm
> <dieter@duenenhof-wilhelm.de> wrote:
>> Signing: When I check the downloads gpg says:
>>
>>   Good signature. Warning: This key is not certified with a trusted
>>   signature!
>
> Hmm.  I've uploaded my key a few places (in addition to posting on
> Savannah).  I can look for other places to publish it -- any
> suggestions?

Thank you 

I think it would be helpful for (some interested) users either to have
it directly at the ftp site (in the gnu-keyring?) or to make / announce
your key know to public keyservers.

It's probably not yet spread on public keyservers.

  $ gpg --keyserver hkp://keyserver.ubuntu.com --search-key corwin@bru.st

You could announce your key on keyservers thus

  $ gpg --keyserver hkp://keyserver.ubuntu.com --send-key corwin@bru.st

I guess only few users will actually check if their download is valid
with the .sig file...  But I remember how annoying it was to search for
a key, when the old key of the developer was expired.

>> Would it help, be appear more trustful, when I sign your key?

> I don't think I quite understand this suggestion -- not a rejection.
> Likely, you are wiser than I in the ways of GPG.

I'm not wiser and most likely this signing of keys isn't worth the
trouble since it seems that Emacs developers just include their keys
into the gnu-keyring and don't build a Web of Trust around it, like, for
example, the Debian project.

>> Size: Your installer and emacs-28.0.91 builds are smaller than Phil's.
>> I assume you didn't copy the source code?
>
> I'm fairly sure the binary release packages have never included
> source.  I suspect the size difference is accounted for by omitting
> -static while compiling.

Ah OK.

>> Installation tree: I've seen that you skipped the x86_64 branch.
>>
>
> Can you elaborate?  Is this a difference between my prior versions and
> the current, between what Philliip was producing and what I've been
> making, or somehow .. both?

Phil's installer (and archives) with a default installation:

c:\
|- Program Files\
   |- Emacs\
      | x86_64\
        |- bin\
        |- ...

Your installer:
c:\
|- Program Files\
   |- Emacs\
      |- bin\
      |- ...


>> > I hope someone with a working msys can confirm that this supports
>> > native-compilation when msys+libgccjit is available.
>>
>> I'm sorry, forgot to check it on my MSYS machine, will do tomorrow.
>
> Quite alright -- as I mentioned in the new thread[1] from today, I was
> able to test the installing to a machine with a working msys (on path)
> does enable native compilation to work, so I'm feeling a bit less
> pressure on that score.  Don't get me wrong: I'll be very happy when
> you are able to take a look.

I didn't comment yet on [1] because I think, in summary, your focus is
well thought out and you don't let yourself be too distracted from my
"firing" on the side-line. :-)

Some observations regarding the native compilation:

After runing Emacs native compilation started immediately till all
el. files were compiled to .eln.  I check with the Process Explorer that
these files are loaded as well.

It seems that you've configured Emacs to do the compilation
"as-soon-as-possible" and not "just-in-time" :-)

Then, unfortunately, for each .eln file (96) there remains an
accompanying .eln.tmp file in the eln-cache!?

When updating some packages (M-x list-packages) these were then native
compiled and respective .eln.tmp files vanished.  (But still not the
.eln file which were compiled in the beginning!)

Bye

  Dieter

> [1] new thread, summary/TODOs:
> https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01467.html

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany