Re: Native compilation: the bird-eye view

[Andrea Corallo]

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?

  Andrea

-- 
akrl@sdf.org