Re: native-comp and resetting of search paths

[Andrea Corallo]

Alex Bennée <alex.bennee@linaro.org> writes:

> 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?

Elns are not only arch dependent but also Emacs version + configuration
dependent, so yeah this is to disambiguates these.

>
> 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 think the issue is that we need a disambiguation at file name level to
retain a reasonably fast loading system.

> 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?

This is because lisp symbols are a superset of valid C ones, so this is
another level of disambiguation but here it does not play a role.

> 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

I don't think we can use '/' in unix filenames IIUC your proposal.

Stefan idea is about making elns completely transparent, you'll find the
link my other mail.

Thanks

  Andrea

-- 
akrl@sdf.org