bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

[Andrea Corallo]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Thu 04 Feb 2021, Andy Moreton wrote:
>
>> On Thu 04 Feb 2021, Andy Moreton wrote:
>>
>>> On Wed 03 Feb 2021, akrl--- via "Bug reports for GNU Emacs, the Swiss army 
>>> knife of text editors" wrote:
>>>>
>>>> Hi Andy,
>>>>
>>>> could you share the values of PATH_DUMPLOADSEARCH and
>>>> PATH_REL_LOADSEARCH from your epaths.h ?
>>>>
>>>> Thanks
>>>>
>>>>   Andrea
>>>
>>> Native branch checkout is in: "c:/emacs/git/emacs/native/"
>>>
>>> "c:/emacs/git/emacs/native/build/mingw64-x86_64-O2/src/epaths.h" contains:
>>>
>>> #define PATH_DUMPLOADSEARCH "C:/emacs/git/emacs/native/lisp"
>>> #define PATH_REL_LOADSEARCH "28.0.50/lisp"
>>
>> I've bootstrapped again after the recent hash shortening to ensure my build
>> is up to date, from commit 1f626e9662d8120acd5a937f847123cc2b8c6e31. The
>> paths above are unchanged.
>>
>> Running this from the build dir, I see messages like:
>>
>> error in process sentinel: Native elisp load failed: "file does not exists",
>>  
>> "c:/home/ajm/.emacs.d/eln-cache/28.0.50-e2ae3598/hl-line-e67628ec-664ef650.eln"
>>
>> This suggests that the AOT .eln files are not being found. It should find:
>>
>> c:/emacs/git/emacs/native/build/mingw64-x86_64-O2/native-lisp/28.0.50-e2ae3598/hl-line-8fa29c14-664ef650.eln
>>
>> The middle hash (e67628ec vs. 8fa29c14) is not the same - any idea why ?
>
> After looking at what `comp-el-to-eln-filename' does, I observe that:
>
> (substring (md5 "c:/emacs/git/emacs/native/lisp/hl-line.el") 0 8)
> "e67628ec"
>
> (substring (md5 "//hl-line.el") 0 8)
> "8fa29c14"
>
> That matches the two middle hashes seen above.
>
> It looks like `comp-el-to-eln-filename` fails to match the filename
> prefix against PATH_DUMPLOADSEARCH. It is using case-sensitive matching,
> but on Windows filesystems are case-insensitive.

Hi Andy,

The Windows filesystem is case-insensitive but the case is preserved
correct?  If so it should work no?

Last queston: do reverse slashes '\' appear somewhere in those
filenames?  This was issue I tried to fix with the blind patch I've
sent.

Thanks

  Andrea