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

From: Nicolas Bértolo <[email-masked]>
Date: Tue, 2 Jun 2020 18:17:38 -0300

Hi,

The recent patches broke the Windows build. There is one patch that
fixes it and another one that improves the way to check for the gccjit version
functions.

Nico.

El mar., 2 jun. 2020 a las 13:24, Andrea Corallo (<[email-masked]>) escribió:
>
> Eli Zaretskii <[email-masked]> writes:
>
> >> From: Andrea Corallo <[email-masked]>
> >> Cc: [email-masked], Eli Zaretskii <[email-masked]>
> >> 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.
> >
>
> --
> [email-masked]