Re: master f8bb6cca33: Return the same file from locate-file in nativecomp and non

[Corwin Brust]

Hi Stefan & everyone,
I hope my questions aren't out of place (and that my message finds
everyone well :)

On Mon, Mar 14, 2022 at 1:12 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >> I assume you don't have a `simple.eln` file in your
> >> `native-comp-eln-load-path`, so nil seems correct.
> > So you are saying that finding the .eln file produced from simple.el
> > is not something we should support, like we do with the *.elc files?
>
> `locate-file` is a function that doesn't rely on external
> config variables.  It should do its job based exclusively on the
> arguments it takes and the state of the file-system.

Are there cases where we can "lie to it", for example giving "false"
information about the state of the file-system by let-binding a
variable or something?

> If you're looking for a file named `simple-<HASH>.eln` then you will
> have to pass that <HASH> either in the first or the third arg.
>
> It can definitely be a useful building block to find a `.eln` file, but
> its job is not to find `.eln` files.

Are you suggesting a way forward could be to pass a pre-fabricated
collection of (e.g.) ELC to ELN mappings, eg. as an optional param to
locate-file?  Would it be equally acceptable to have that list in a
def{{var custom} that locate-file knows to look?  Can you share more
on why one or the other of those is "obviously worse/better" than the
other (if either is)?

Please do feel welcome to disregard if these questions are unhelpful
to moving the conversation forward.

FWIW, I think it would be nice to "easily discover" all of the
relevant source file locations for any natively compiled sources I may
have loaded.  That said, I do not seem to be sitting on any sort of
code toward solving for this, nor perhaps am I properly understanding
the problem space.

Appreciate all your guidance,
Corwin