bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file.

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 41242@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> Date: Mon, 01 Jun 2020 19:24:43 +0000
>> 
>> In which folders are we going to search if we do (load "...a/path/foo.eln")?
>> 
>> I believe in this case we should search the file only in "...a/path/"
>> because the user really want to load this specific file.  Am I correct?
>
> Isn't that already so when we look for *.elc files?

Yes but here the hash directory that we use to disambiguate the triplet
comes into play so we search there too.  This is what Nico posted about
what we would probe for a load.

(load "C:/dir/foo.eln")

"c:/dir/foo.eln.eln"
"c:/dir/eln-hash/foo.eln.eln"
"c:/dir/foo.eln.dll"
"c:/dir/foo.eln.elc"
"c:/dir/foo.eln.elc.gz"
"c:/dir/foo.eln.el"
"c:/dir/foo.eln.el.gz"
"c:/dir/foo.eln"
"c:/dir/foo.eln.gz"

My argument was that in the case of (load "C:/dir/foo.eln") we should
try to load only "c:/dir/foo.eln" without having to look into
"c:/dir/eln-hash/".

But Nico pointed out (probably correctly) that the function is already
quite dumb regarding ignoring extentions and is probably not worth doing
an exception for this.

>> That said IMO this logic is sufficiently complex to deserve a minimum of
>> testing to make sure we have it under control.  Not sure if the best
>> place is files-tests.el or comp-tests.el.
>> 
>> Maybe Eli likes to gives his opinion on this last point and on the patch
>> in general.
>
> I think the logic should be consistent with how we search for Lisp
> files in general.
>

-- 
akrl@sdf.org