bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii]

> Date: Fri, 24 Sep 2021 13:48:09 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org
> 
> > Cc: 50666@debbugs.gnu.org
> > Date: Fri, 24 Sep 2021 07:32:11 +0000
> > From:  Andrea Corallo via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > 
> > > Can you point me to the part of the discussion where it was determined
> > > that the absolute location of the file was making a difference that was
> > > not covered with the hash of the content?
> > 
> > Not at the moment sorry, this was discussed more the once in different
> > threads in the last 1-2 years.
> 
> Right.
> 
> One situation that comes to mind is that a .el file could be
> native-compiled with different versions of macros in scope, although
> that is not necessarily evidenced by the file's absolute name.

I think I know what we were trying to solve by that, but the
explanation is a bit hairy.

It begins by noticing that what goes into the file-name part of the
hash is not the entire absolute file name.  We cannot use the entire
absolute file name, because then moving the .el files somewhere else
(e.g., to relocate the entire tree, or maybe access it from a
different machine) would break loading the *.eln files.  So we
actually disregard the leading directories, leaving just what's below
the 'lisp/' part.  For example, for a file "/foo/bar/baz/lisp/FOO.el"
we use just "//FOO.el".  And that could cause problems if we also have
"/foo/bar/baz/lisp/subdir/FOO.el".  So for the latter we use
"//subdir/FOO.el", which gives a different hash.

IOW, this is to be able to distinguish files with the same base name
that reside in different sub-directories of the same tree.