Re: Native Compilation And External Packages

[T.V Raman]

"T.V Raman" <raman@google.com> writes:
Following up to myself before shutting down for the night:

1. '-f batch-byte-native-compile-for-bootstrap'
   gives me most of what I was looking for -- ie produces correctly
   built emacspeak eln files, and there are now no Warnings when running
   the resulting build.

   2. Caveats: For a while I was lost as to where the .eln files were
      gone, to avoid confusion I cleaned up .emacs.d/eln-cache -- still
      couldn't find any emacspeak eln files after a fresh build.

      Turns out that calling the bootstrap builder puts the eln files in
      the emacs source tree -- this works for me for now since I am
      running native-emacs from the source tree -- but we may well need
      a better solution.

      I will still try and file bugs tomorrow as appropriate -- but the
      present "circularity " that forces me to use the bootstrap
      builder:

      A. batch-native-compile does not produce .elc files.
         B. This means that your Makefile %.el:%.elc rule wont work, if
            the elc files are present make wont do anything; if you
            delete the .elc files, the native compiler runs, but you
            dont have any .elc files so the package might not start up
            (emacspeak doesn't).

            C. going the bootstrap route also appears to avoid bugs
               where the native compiler is overly aggressive and tries
               to jit files that were earlier compiled via
               batch-native-compile.

               

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> I'll write up these as bug reports, now that I have a somewhat better
> sense as to what it is I am reporting.
>
> At present, there appears to be a lot of "magic" in the bits around jit
> compilation, when emacs decides to generate a new .eln file etc, which
> makes it hard to discern a bug from a feature and consequently, phrasing
> a sensible question is hard as these threads have demonstrated.
>
> Also, I suspect that filing a bug report would have caused folks looking
> at it to "file a simple   repro case", and that is something I
> definitely wont be able to do given that I'm chasing this down with a
> fairly large package as the use-case.
>
>
>
>> T.V Raman [2021-05-29 10:14:43] wrote:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> The warnings are inconsistent as in:
>>
>> Please, please, pretty please write this in a bug report.
>>
>> Or better yet, two bug reports: one for the case where you replace
>> `batch-byte-compile` with `batch-native-compile`, and another for the
>> case where native compilation takes place lazily.
>>
>> The "extra warnings" during lazy native compilation is a known problem,
>> but one we need to address, so making a bug report about it will
>> be helpful.
>>
>> The problems you mentioned when replacing `batch-byte-compile` with
>> `batch-native-compile` OTOH are not known, AFAIK, so we really need
>> a clear bug report with details of what you did, what that got you, and
>> why you think it's wrong about that.
>>
>>
>>         Stefan
>>
>>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
?7?4 Id: kg:/m/0285kf1  ?0?8