Subject: bug#44701: closed (Re: bug#44701: 28.0.50; [feature/native-comp] Use file-truename when building eln path hash)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 18 Nov 2020 20:58:01 +0000

Your bug report

#44701: 28.0.50; [feature/native-comp] Use file-truename when building eln path hash

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
44701: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=44701
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#44701: 28.0.50; [feature/native-comp] Use file-truename when building eln path hash
From: Andrea Corallo <[email-masked]>
To: Tad <[email-masked]>
Cc: [email-masked]
Date: Wed, 18 Nov 2020 20:57:55 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

Tad <[email-masked]> writes:

> This makes it possible to load AOT-compiled .eln files from the Nix
> store, so thank you for implementing this change.

That's good to hear!  Thank you for reporting, closing.

  Andrea

Subject: 28.0.50; [feature/native-comp] Use file-truename when building eln path hash
From: Tad <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 16 Nov 2020 20:03:15 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

It appears that `comp-el-to-eln-filename` uses `expand-file-name` to
determine the absolute filename to
hash. When the filename is a symlink, this results in a cache miss
depending on which path is loaded.

`file-truename' would be the equivalent to `(expand-file-name name
nil)`, except that it would resolve to a
single canonical path (in the absence of hardlinks, which is pathological).

If I may ask, what is the purpose behind the path component of the
hash? I would think a content hash
would suffice to disambiguate files in the .el<->.eln bijection.

Thanks,
Tad