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

[Corwin Brust]

On Fri, Feb 4, 2022 at 7:29 PM Drew Adams <drew.adams@oracle.com> wrote:
> > Just to confirm:
> > 1. does the machine where this occurs have MSYS including libgccjib
> > and gcc, and if so
>
> No idea, but most likely not.  It's not a software
> development laptop.  No gcc or other C compiler,
> for sure.

Than it is indeed a mystery why we are getting an error related to not
finding libgccjib.  As best we expect (and to the extent of my still
fairly limited understanding, it is true that) ... [this sentence will
be right back, after after these further inline quotations]

>
> > 2. is bin folder of that MSYS installation on your path?
>
> No MSYS, most likely.
>
> > As I strongly suspect you know: We aren't providing libgccjib+gcc with
> > the Emacs 28 distributions, at least we haven't decided to do that so
> > far.
>
> No, I don't know.  And I don't know what libgccjib+gcc
> is, or why I would want or need it on my laptop.

... we do not need to have MSYS, much less libgccjit, to use an Emacs
binary that has been compiled with support for native compilation.
Natively compiling additional ELN won't be possible and shouldn't be
attempted in that case.  That said, when MSYS (or GCC or libgccjit)
isn't installed (or isn't on the path when we start Emacs, even so the
(currently very few) ELN files provided with the release should work.
In my testing this has held true.

>
> I also don't understand, if Emacs native compiling
> tries to use existing *.elc files, why it doesn't
> fall back to using the *.el, if trying to compile
> natively from the *.elc raises an error.

I'm fairly sure Emacs is not (at least, should not be) trying to
execute native compilation.


>
> IOW, in the case of this small Elisp file, why would
> Emacs depend on using a *.elc if present, and simply
> give up if trying to use it raises an error.  The
> source of truth is (should be) *.el, not *.elc.

That sounds like a feature request to me:

[wishlist] When an error occurs loading the ELC, attempt loading from
the EL file (given the EL file is present locally).  Note, I didn't do
any research to see if this could already be supported

[[Hope the capitalized file-extentions aren't making this --even--
harder to parse.  I find them easier to read in the midst of human
facing text vs seeing short not-actual-words in the same places.  Let
me know if that's offputting.]]

>
> I can maybe understand that starting with a *.elc
> might be a useful shortcut of some kind, but why
> should an error with a *.elc - especially of the
> sort that some compiling tool etc. isn't available
> - prohibit using an Emacs binary?  Since when
> should an Emacs binary depend on such things?
>

An ELC file, when present, is considered the primary "machine
readable" source for the feature, wnless the corresponding ELN exists
in which case it is.  More on this further down.

I was assuming you tried to use your elc intententioonaly as a way to
test the new binaries, and that you have good  reason to expect that
to work.  For myself (in terms of my own use of Emacs), I keep
separate package repository (ELPA) folders for each installed version
of Emacs.  I thought that was required, at least in as much as I want
to be able to (e.g.) run Emacs 27 sometimes, but I don'tt want errors
from packages that may have been compiled with Emacs 28 or snapshot
builds.   I treat my ELC files as disposable but take care these days
to hang on to my EL files, and go to pains to fetch (and usually
byte-compile) them during startup when they aren't around.  That's a
bit of a different use-case, tho, I believe.

Can you confirm it is expected that byte-complied files are promised
to be forward compatible?  This is outside my experience.

AFAIK, from the Emacs developer perspective, the "most compiled" form
of an elisp package becomes it's "machine readable feature" file and,
as such, that should be the only version which is technically needed
for Emacs to support what functionality it provides.  So, in the case
of an ELC being present, removing the EL file completely should be
harmless:  it is essentially documentation and ought to safe to remove
when the user/distro doesn't want it.  In point of fact, I can't
remember reading about whether it's safe for end-users (or distros) to
remove an ELC when using/shipping an ELN for the feature.

> If it's no longer possible to use a Windows binary
> unless you have such development tools installed,
> then Emacs 28 and later will be useless, for me at
> least.

Fortunately, this is not the case.  Neither by intention nor (so far
in my own testing) in fact.

>
> > Appreciate the backtrace; I'll reply again when
> > I can attempt testing in a sans-MSYS environment.
>
> I take that as a hopeful sign that the _intention_
> is not to require dev tools such as gcc, msys etc.
> to be present on the machine where I use an Emacs
> binary.

That's quite correct, thus my troubling two of my kiddos for use that
mostly run Minecraft and block-vader, or whatever it is.  On one I
have added MSYS, on the other not.

>
> If that's the intention then great, and I wish you
> good luck getting past this hurdle.  Sorry to be
> the bearer of the bad news that there are some
> Emacs users who don't use software dev tools.
>

That's no news at all.,  At my day-job (generally speaking) I am one of them :)

> Maybe that will ultimately mean that such users
> must forego being able to use natively compiled
> code?  If so, that's OK by me - no worse than before.

I hope not.  As far as I've seen when testing without MSYS, Emacs is
able to load and utilize ELN files even when MSYS isn't available.
(Although it can't create/update any ELN files, notwithstanding your
experience, I haven't found any place where it errors out because,
e.g. libgccjit is missing.)

>
> It's likely that some of what I just wrote betrays
> false assumptions or misunderstandings on my part.
> I haven't been following the attempt to provide
> native compilation.

I think (hope) so, yes.  I've done my best to speak directly to these
but let me know where I may have failed.

To summarize my own understanding/expecations:

- Emacs works fine when MSYS isn't around
- Nattive Comp is only available when MSYS is around
- ELN files are created only when Native Comp is available
- ELN files are preferred when they are present
- ELC files are used when no ELN exists
- EL files are used only when no ELC exists
- We are warned loading an ELC newer than it's EL
- Likewise when loading an ELN newer than it's ELC

I hope and trust that you will LMK if anything I've said suggests what
you are trying may not be supported (and likewise for anything
seeminly untrue or very unexpected in what I've said).

Corwin