[Top][All Lists]

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

Re: Native compilation: the bird-eye view

From: Stefan Monnier
Subject: Re: Native compilation: the bird-eye view
Date: Mon, 24 Aug 2020 09:31:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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


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


reply via email to

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