[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add a configure option for NATIVE_FULL_AOT?

From: Eli Zaretskii
Subject: Re: Add a configure option for NATIVE_FULL_AOT?
Date: Tue, 17 Aug 2021 20:13:08 +0300

> From: Tom Gillespie <tgbugs@gmail.com>
> Date: Tue, 17 Aug 2021 09:03:45 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>
> > My fear is that this change of concept will delay the release of Emacs
> > 28, because we are moving the carpet under our feet too close to
> > cutting the release branch, and will most probably bump into problems
> > we didn't see until now.
> I don't think that there is any change of concept here.

Maybe for you and some others, but it doesn't mean there isn't a
conceptual shift.  I've been following the development of the
native-compilation feature for many months, during which we bumped
into and resolved quite a few problems with it, and I can tell you
that some solutions explicitly assumed JIT compilation as the main
paradigm, otherwise they would have made little sense.  I just
mentioned some of them up-thread.

> This was one of the original ways to build the eln files and I have
> been using it for over a year.

I'm not talking about you or anyone else personally.  The issues we
found depend on many different installation/usage habits and patterns,
and typically rear their heads only on some system configurations.  It
is not a coincidence it took us several months to have all the issues
reported, analyzed, and resolved.  Some of the solutions required
several iterations of non-trivial changes to code parts that are quite
sensitive, because Emacs runs them early during startup, where not
everything is yet set up.

> I understand the concern, but wouldn't it be better to get the functionality
> out so that we can get more eyeballs/systems using it to see if there are
> any issues?

I'm not against letting this out, I'm just saying that it will
probably delay the release of Emacs 28, which is a pity.

> > Also, please note that the *.eln files are stored without keeping the
> > subdirectory structure below lisp/, they are all lumped in the same
> > directory, unlike the *.elc files.  I guess next we will be asked to
> > preserve the tree structure...
> We had this conversation almost exactly a year ago as well.
> https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg01036.html
> The eln files are architecture specific and should not be stored along
> with the elc files

I didn't say *.eln should be near the *.elc, I said that they maybe
should have the same directory hierarchy as the *.el files, just under
a different root.

> Quite a bit of though and testing have gone in to make sure that
> system wide full AOT compilation works and is distro and packaging
> friendly.

I didn't invest any thought in it, FWIW.  For me, it was always a "you
are on your own" option.  I didn't even try it, as all of the efforts
went into making the JIT compilation working well and reliably.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]