bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int


From: Andrea Corallo
Subject: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int
Date: Wed, 31 Mar 2021 19:22:54 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: andrewjmoreton@gmail.com, dmalcolm@redhat.com, 46495@debbugs.gnu.org
>> Date: Wed, 31 Mar 2021 18:52:55 +0000
>> 
>> >> Is the application responsible for cleaning up temporary files in '/tmp?
>> >> If yes then yes... I guess we should :)
>> >
>> > I think it's good practice, yes.
>> 
>> 8e524f4591 fix this.
>
> Thanks, confirmed.
>
> Btw, I have now 3 different *.eln files for comp.el in the same
> subdirectory of native-lisp:
>
>   comp-7672a6ed-ad0cbb8b.eln
>   comp-7672a6ed-58fb0518.eln
>   comp-7672a6ed-9f0b1563.eln
>
> Is this expected?  What does the second hash depend on?

The second hash is the one based on the source file content.

I see why, every time we compile a new eln we call
`comp-clean-up-stale-eln' to remove the old .eln.  But we exclude from
the clean-up the eln system directory (the last in
`comp-eln-laod-path').

I don't remember if the reason is that when Emacs is installed this is
typically read only or there's some other reason.  Probably we should
remove this limitation and handle correctly the case where we are not
able of removing the file if necessary.

  Andrea





reply via email to

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