[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: native-comp and resetting of search paths

From: Alex Bennée
Subject: Re: native-comp and resetting of search paths
Date: Tue, 14 Jul 2020 09:04:05 +0100
User-agent: mu4e 1.5.4; emacs 28.0.50

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]