emacs-orgmode
[Top][All Lists]
Advanced

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

Re: Reproducible work with natively compiled Emacs


From: Pedro Andres Aranda Gutierrez
Subject: Re: Reproducible work with natively compiled Emacs
Date: Sat, 16 Mar 2024 07:16:05 +0100

Hi Ihor,

Answer inline...

On Fri, 15 Mar 2024 at 18:08, Ihor Radchenko <yantar92@posteo.net> wrote:
Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> I have added the eln version to the patch...
>
> Best, /PA
> PS: Just as an example, I recompiled master today and the version number
> for eln changed, so the 'old' files from yesterday were not removed ;-)

Yeah. Not ideal.
The whole system with emacs -Q putting things into .emacs.d is not ideal.

Sometimes, when running things like make test we do not even want to
litter .emacs.d - .eln files generated during make test might correspond
to the broken versions of Org mode that were being tested. Then, running
actual working Emacs session might stumble upon these incorrect versions
of .eln files.

Do I understand correctly that the reason you implemented cleaneln make
target is working around issues with make test/make repro?

Yes, that's one of the reasons. And, also because when I set native.comp-eln-cache-path,
anything that is not part of the Emacs distribution gets compiled into that directory. For example,
the clone of org-mode main as well as the packages from elpa/melpa/nungnu.

When refreshing my local copy of the org-mode repo, I start with a make cleaneln before pulling and then
make native. Thus I get a predictable build.
 
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Best, /PA

--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet


reply via email to

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