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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: phillip.lord@russet.org.uk,  emacs-devel@gnu.org
>> Date: Sat, 30 Jan 2021 20:17:58 +0000
>> 
>> >> native-lisp/28.0.50-x86_64-w64-mingw32-HASH1/titdic-cnv-HASH2-HASH3.eln
>> >> 
>> >> - HASH1 disambiguate triplet, Emacs configuration, version etc.
>> >
>> > But that information is already present in the text before:
>> > 28.0.50-x86_64-w64-mingw32.  What else is missing that we need a hash?
>> 
>> I left the text before as indicative and human readable but
>> unfortunatelly that's not complete.
>> 
>> The list of all primitive functions contribute to the eln linking
>> mechanism we use and is accounted in this hash.  Also we can trigger the
>> generation of a new hash each time we deploy an eln ABI breaking change.
>
> Sorry, I don't follow.  You said HASH1 disambiguates the triplet, and
> that is already present in the name.  Please elaborate on the other
> factors that affect HASH1, as what you said (primitives that
> contribute? eln ABI breaking changes?) isn't enough for me to
> understand what information they record.

Sure,

each .eln while executing must indeed call into Emacs C code.  Call
happens through function pointers, say we must call Fmessage, something
like this will be rendered into the eln:

freloc_link_table->Fmessage (...)

'freloc_link_table' is a pointer statically allocated within the eln
object, it gets set while loading to point to the right data structure
in memory.  This data structure is a C structure holding all function
pointers to all Emacs primitive functions.

For this reason we must be sure that the definition of
'freloc_link_table' use while compiling the eln matches the one offered
by the Emacs loading the eln file.

This is the main reason eln are not portable between different Emacs
configurations.

HASH1 has the duty to disambiguates this and everything else that could
reflect into an incompatibility of the eln (`system-configuration`
`emacs-version`).

As from time to time we can refine mechanisms like the load mechanism or
anything else and consequentially generating another incompatibility the
macro ABI_VERSION also contribute to HASH1.  I bump a new number there
each time I realize I'm changing something that introduce and
incompatibility.

To summarize eln was never designed for compatibility across versions or
configurations and HASH1 is made to guard against that.

> And in any case, if the triplet is in HASH1, why not remove its
> human-readable representation and save a few bytes?

At the time was thought to be convinient to have the triplet also as
human readable.  Indeed no problem from my side on removing it if this
is problematic (wasn't aware of this Windows limitation).

That said I think the main cure for this Windows file length issue is to
diet down the hash length to something more reasonable (16 or 8
characters?).

Regards

  Andrea