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

[akrl--- via "Emacs development discussions." <emacs-devel@gnu.org>]

Andy Moreton <andrewjmoreton@gmail.com> writes:

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

Sorry typo; wanted to write path, so please read 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.

Please design and implement such a system, when will be proved it works
well I'm sure these patches will be welcome.

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

No, HASH2 is not influenced by eln compilation flags.

  Andrea