bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on st


From: Lars Ingebrigtsen
Subject: bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup
Date: Fri, 14 Oct 2022 12:53:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps we should make the no-native-compile thing into code instead of
> having it as a comment? 

I started futzing around with this again, but then wondered whether we
should have a more general language mechanism for stuff like this.  So
I've added Stefan to the CCs; perhaps he's thought about this stuff
before.

So to recap the practical problem we have today and would like to fix:

We put

;; 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.

This is simple enough, of course -- we could just introduce a
(no-native-compile) function that hooks into the machinery at the right
point.

But this reminds me of other "file-wide directives" that have been
previously discussed over the years, and makes me wonder whether we
should introduce something more general.

As an example of an ad-hoc one that already exists, we have `defgroup'
that makes all subsequent `defcustom' forms use that group in the same
file.  We've previously discussed (in i18n contexts) whether it should
be possible to specify the translation domain of the file.  And we have
different Emacs Lisp dialects, and we have shorthands, which use
comments to change the behaviour of the code, which is unsatisfactory.

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.  We could have

(pragma 'dynamic-binding)

for future versions of Emacs when lexical binding is default but we want
to allow people files to still be dynamic.

And we could have

(pragma 'shorthands "snu-" "some-nice-string-utils-")

And, of course, for backwards/forwards compat, any unknown pragmas would
be ignored.






reply via email to

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