Re: Native compilation: the bird-eye view

[Stefan Monnier]

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

>> Note that for the "system-wide" .eln files it can be trickier because we
>> may want to generate them once and then use them with Emacs installed at
>> difference locations, so we'd then want to try and avoid using the
>> absolute file name (and instead use file names that are relative to the
>> root of the Emacs install or something).
>
> I think in this case we could generalize what we have in place now to
> allow reusing the same eln for local build and installed.
>
> We are currently replacing in the filename if matches
> PATH_DUMPLOADSEARCH or PATH_LOADSEARCH with '//' before feeding the hash
> algorithm.

Sounds good,


        Stefan