Re: native-comp and resetting of search paths

[Alex Bennée]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Hmm odd. It's a custom variable:
>>>
>>>   (defcustom elpy-rpc-pythonpath (file-name-directory (locate-library 
>>> "elpy"))
>>>     "A directory to add to the PYTHONPATH for the RPC process.
>>
>> Use (locate-library "elpy.el" t); that will find the .el file, not one
>> of the compiled files.
>
> This will workaround the incompatibility introduced by the native-comp
> branch, but we should probably try and see if we can change the way the
> branch works such that such incompatibility is avoided.

Is there a particular reason why .eln files are stored in a
sub-directory?

I would guess there is a concern about clashing between versions of the
compiler and different architectures on network file-systems?

The .eln files themselves are ELF files so we could just shove any extra
metadata in there although I don't know if that becomes expensive
compared to a simple file-path check?

I assume the byte-compiler potentially has similar problems if a user
runs two different versions of Emacs but we don't dump .elc files in
special locations. Is this just not a concern that hits often enough or
something that is detected and dealt with by Emacs itself?

I note the symbols in the eln files also have fairly unique identifiers
so maybe we are attempting to avoid a problem that's not really there?

I realise that was a lot of questions so maybe I should just propose the
eln stay in the directory of the source files and have a form like:

  <source dir of .el>/<basename>.<arch>.eln

-- 
Alex Bennée