unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "T.V Raman" <raman@google.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
Subject: Re: Native Compilation And External Packages
Date: Sat, 29 May 2021 18:58:52 -0700	[thread overview]
Message-ID: <p91eedprnhf.fsf@google.com> (raw)
In-Reply-To: <jwvczt92x9z.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sat, 29 May 2021 14:52:26 -0400")

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2530 bytes --]

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



  reply	other threads:[~2021-05-30  1:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-29 16:28 Native Compilation And External Packages T.V Raman
2021-05-29 16:38 ` Eli Zaretskii
2021-05-29 17:14   ` T.V Raman
2021-05-29 17:36     ` Eli Zaretskii
2021-05-29 18:52       ` Stefan Monnier
2021-05-30  1:58         ` T.V Raman [this message]
2021-05-29 18:56     ` Stefan Monnier
2021-05-30  2:06       ` T.V Raman
2021-05-30  3:05         ` T.V Raman
2021-05-29 17:00 ` Stefan Monnier
2021-05-29 17:18   ` T.V Raman
2021-05-29 18:36   ` T.V Raman
2021-05-29 18:47     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p91eedprnhf.fsf@google.com \
    --to=raman@google.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).