GNU bug report logs - #57627
29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: germanp82 <at> hotmail.com, 57627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <akrl <at> sdf.org>
Subject: bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup
Date: Fri, 14 Oct 2022 15:00:00 -0400

> ;; no-native-compile: t
>
> into .el files to signal that we don't want them to be native-compiled.
> However, the machinery today doesn't see that when we want it to.  That
> is, we load the .elc file, the nativecomp machinery then kicks in and
> adds the file to the async .eln list, which then forks off an Emacs
> which then loads the .el file and sees that cookie, and then does
> nothing.  (And this will happen on every Emacs run.)
>
> So the machinery either has to inspect the .el file in addition to the
> .elc file (which is inefficient), or we need to put something into the
> .elc file to tell the machinery not to bother with generating the .eln.

After spending many milliseconds thinking about it, my conclusion is
that the bytecompiler should add a little code snippet like
(puthash load-file-name t comp--no-native-compile) in the
file if `no-native-compile` was specified.  So it then be easy for the
lazy native compilation to detect that it should skip this file (since
lazy native compilation is triggered after loading the file) by just
consulting `comp--no-native-compile`.

For that, there's no need to change the way `no-native-compile` is specified.

> So...  is it time to introduce something like `pragma'?
>
> That is, in this case, we'd say
>
> (pragma 'no-native-compile)
>
> somewhere in the file.

I guess that could work for `no-native-compile`, indeed.  But if you ask
to native compile this file and the pragma is halfway down the file,
what happens?

> We could have
>
> (pragma 'dynamic-binding)

I guess this one could work (of course, it'd have to be at top-level),
and we could switch back&forth within the same file (yuck!).

But if we allow such `pragma` to be output by macros, then it becomes
tricky for `eval-region` to reliably decide which dialect to use.

> And we could have
>
> (pragma 'shorthands "snu-" "some-nice-string-utils-")

Same question: the tooling will often want to have access to that
information but without necessarily wanting to run (or macroexpand) all
the code first.

So we could allow such `pragma`, but we'd likely end up restricting its
syntax so we're able to find it with something like a regexp search, so
in the end it's not clear what's the advantage over
file-local variables.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.