[Top][All Lists]

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

Re: [feature/native-comp] breakage on build

From: Andrea Corallo
Subject: Re: [feature/native-comp] breakage on build
Date: Sat, 30 Jan 2021 19:44:56 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 30 Jan 2021 18:38:10 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: akrl@sdf.org, emacs-devel@gnu.org
>>   compiling to
>> c:/msys64/home/Administrator/emacs-build/build/emacs-28.0.50-snapshot-feature_native-comp-windows/native-lisp/28.0.50-x86_64-w64-mingw32-3459bc949453c7833f94b407f8ee7c17/titdic-cnv-765ac3beca7090ba17f799d9600c18e6-a5dbcc84a969a94717512a079e1cc96a.eln
>> The name of that file is suspiciously close to the 260-byte limit of
>> file-name length that Win32 APIs support.  So my guess is that the
>> temporary file had a few more characters (like the 6 characters which
>> replace the XXXXXX, perhaps?), and that caused the failure.
> Btw, Andrea: why do we need no less than 3 32-character hashes in that
> file name?  With 26-byte limit on file names that libgccjit can use,
> these 96 characters use up almost half of that space, and that will
> bite us time and again down the road on MS-Windows.  Can we use just
> one hash?

Say ATM we have:


- HASH1 disambiguate triplet, Emacs configuration, version etc.  We can
  say this is disambiguating everything that influence the ABI the eln
  expects and exposes.

- HASH2 is just hashing the full patch of the original source file.

- HASH3 is hashing the content of the file.

HASH1 is handy because one can remove selectively the eln files of say a
previous Emacs version or an old configuration.  I often remove all of
these folders but the most recent one.  That said technically HASH1 and
HASH3 could be merged.

HASH2 is handy because there must be within this folder at most one file
with each HASH2.  IOW recompiling we remove all the other .eln sharing
the same HASH2 if present as indeed these files are obsolete.

The lenght of these hashes is coming directly from the algo we use
(md5), I think collision is really not an issue so we can easlily short


reply via email to

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