bug#47987: 28.0.50; [native-comp] Can't compile ELN if EL and ELC reside in different directories

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Tassilo Horn <tsdh@gnu.org> writes:

> I use mu with its mu4e Emacs package for reading my mail.  I have it
> checked out as
>
>   ~/Repos/el/mu/
>
> and the *.el files are in
>
>   ~/Repos/el/mu/mu4e/.
>
> Mu can be build with the meson build tool which places the build
> artifacts in a separate build/ subdirectory, so the executables are in
>
>   ~/Repos/el/mu/build/mu/
>
> and the *.elc files are in
>
>   ~/Repos/el/mu/build/mu4e/.
>
> I've added both ~/Repos/el/mu/mu4e/ and ~/Repos/el/mu/build/mu4e/ to
> `load-path', so `C-h f mu4e' says
>
>   mu4e is an interactive compiled Lisp function in ‘mu4e.el’.
>
> i.e., it has loaded the compiled file and the help links to the source
> file (probably because I've set `load-prefer-newer').  Perfect!
>
> However, the native compiler complains that it cannot find the source
> files in a *Warnings* buffer:
>
> Warning (comp): Cannot look-up eln file as no source file was found for /home/horn/Repos/el/mu/build/mu4e/mu4e.elc Disable showing Disable logging

[...]

> As the no-native-comp emacs has no problem locating byte-compiled and
> source file, the native-comp emacs shouldn't have that problem, too.
>
> In the information below, see that mu4e's byte-compiled files are listed
> as load-path-shadows, shadowing the source files.

Hi Tassilo,

The trouble is that given the bytecode being loaded Emacs needs to find
the source file, both to native compile it (if necessary) both to hash
it in order to the locate the correct .eln file to load.

Now given the .elc file removing the final 'c' was the simple algo
applied for this scope :)  But is this is not sufficient we have to
either provide a more sophisticate mechanism so that a package can
register a new mapping or either disable eln load for some package.

Thanks

  Andrea