Re: Native Compilation And External Packages

[T.V Raman]

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


I think you nailed it!

Note that I dont rely on "any weird" dependency tricks, I do exactly
what Emacs itself does by generating a loaddefs file that contains the
right autoloads, so that that file can be pulled in during compile time
for compiling the .elc file for each module.

The emacspeak-preamble file contains Emacspeak's own core "require "
statements as well as a couple of critical macros.

Eli's suggestion to use the bootstrap related build function is
something I'll try next -- that might well help.

I'll see what emerges in the next couple of weeks, then write things up
as appropriate --- Eli in a nutshell, what I'm trying to do is
effectively now spread over a few threads from me -- TL;DR: "I'm trying
to compile and use Emacspeak " which works, But at present it produces
warnings that looks spurious and there may well be corner cases that are
broken, though I've not found any.

The Emacspeak  codebase is  strict with respect to byte-compiler
warnings, I dont have *any*  in the core --- and package-specification
extensions compile with no warnings as long as the dependent package is
installed.

--Raman

>>> The warnings are inconsistent as in:
>>> 
>>> Compiling at the command line using -f batch-byte-compile produces no
>>> warnings; the same code produces warnings when native-emacs is run
>>
>> A Stefan says, these are real problems that you should report.  they
>> are not false warnings.
>
> IIUC he refers above to the case where his Makefiles only generate the
> .elc and the .eln are auto-generated lazily later.  This is a known
> issue.
>
> IMO it should be fixed by making the lazy native compiler take the .elc
> file as input instead of restarting from the .el file; those "extra
> warnings" we get are due to dependencies not being loaded into the Emacs
> session that does the native compilation and these missing dependencies
> can cause macro-calls to be compiled as function calls, IOW we may end
> up miscompiling the files.
>
> But of course, part of the blame is in the .el files themselves which
> should not depend on special Makefile tricks to get the right files
> preloaded, but it can require a fair bit of work to fix an existing
> package w.r.t such problems.  Also, this used to work so we should
> strive to keep it working.
>
>
>         Stefan
>
>

-- 

Thanks,

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