[Top][All Lists]

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

Re: Native compilation: the bird-eye view

From: Andrea Corallo
Subject: Re: Native compilation: the bird-eye view
Date: Mon, 24 Aug 2020 14:09:55 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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

>>> What I was thinking of doing was: when we generate a new .elc file, just
>>> before saving the file over the old .elc file, we compute the hash of the
>>> old .elc file and erase any matching .eln file.
>> Remeber ATM the input to the ashing is the .el content and not the .elc,
>> this motivated by:
> Hmm...
>>   - The .elc may not capture all the input to the compilation that have
>>     an effect on the native code generation (I don't have a working
>>     example for this is just a suspect).
> The problem is the opposite: it's the .el file which doesn't
> account for the complete information (e.g. you may have to recompile
> a .el file even if it hasn't changed, because some of the macros it
> uses have been modified).
> The .elc files are less affected by such problems.

Very good point.

Considering the two problems:

1 having a way to identify the eln filename from source or bytecode file

2 prevent dlopen to be called two times with the same filename (before
  the initial returned handler is closed).

I believe we could work around ourself problem 2 identifying the
specific condition that is: we are loading an eln filename that is
currently dlopend.  In this case we could temporary rename the eln just
for having it loaded correctly.

If we do this we solve 2 and reloading always works, 1 should be we
already solved.

How does it sounds?



reply via email to

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