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

[Andy Moreton]

On Sat 30 Jan 2021, akrl--- via "Emacs development discussions." wrote:

> 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:
>
> native-lisp/28.0.50-x86_64-w64-mingw32-HASH1/titdic-cnv-HASH2-HASH3.eln
>
> - 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.

This is unclear. Did you mean the content of the source, or its filename ?

> - 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.

This should be done: it is better to simplify the filesystem layout and
provide some utility functions to help with removing stale cache entries.

> 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.

So if the same source same rebuilt with different eln compile flags then
only one of them is retained ? That would need to change if HASH1 and
HASH3 are merged for the .eln filename.

    AndyM