comparison lispref/compile.texi @ 90105:7e3f621f1dd4

Revision: [e-mail]--gnu-2005/emacs--unicode--0--patch-15 Merge from emacs--cvs-trunk--0 Patches applied: * [e-mail]--gnu-2005/emacs--cvs-trunk--0--patch-95 Merge from gnus--rel--5.10 * [e-mail]--gnu-2005/emacs--cvs-trunk--0--patch-96 Move Gnus images into etc/images * [e-mail]--gnu-2005/emacs--cvs-trunk--0--patch-97 - [e-mail]--gnu-2005/emacs--cvs-trunk--0--patch-105 Update from CVS * [e-mail]--gnu-2005/gnus--rel--5.10--patch-14 Merge from emacs--cvs-trunk--0 * [e-mail]--gnu-2005/gnus--rel--5.10--patch-15 Update from CVS: lisp/imap.el (imap-log): Doc fix. * [e-mail]--gnu-2005/gnus--rel--5.10--patch-16 Merge from emacs--cvs-trunk--0

90104:a01e7a9f1659

unless the file specifies otherwise.  This is so that compilation gives
results compatible with running the same file without compilation.
@xref{Loading Non-ASCII}.

  In general, any version of Emacs can run byte-compiled code produced
by recent earlier versions of Emacs, but the reverse is not true.  A
major incompatible change was introduced in Emacs version 19.29, and
files compiled with versions since that one will definitely not run
in earlier versions unless you specify a special option.
@iftex
@xref{Docs and Compilation}.
@end iftex
In addition, the modifier bits in keyboard characters were renumbered in
Emacs 19.29; as a result, files compiled in versions before 19.29 will
not work in subsequent versions if they contain character constants with
modifier bits.

@vindex no-byte-compile
  If you do not want a Lisp file to be compiled, ever, put a file-local
variable binding for @code{no-byte-compile} into it, like this:

byte-compile.  Macro calls are expanded when they are compiled, so the
macros must already be defined for proper compilation.  For more
details, see @ref{Compiling Macros}.  If a program does not work the
same way when compiled as it does when interpreted, erroneous macro
definitions are one likely cause (@pxref{Problems with Macros}).

  Normally, compiling a file does not evaluate the file's contents or
load the file.  But it does execute any @code{require} calls at top
level in the file.  One way to ensure that necessary macro definitions
are available during compilation is to require the file that defines

  However, if you have built Emacs yourself and use it from the
directory where you built it, you will experience this problem
occasionally if you edit and recompile Lisp files.  When it happens, you
can cure the problem by reloading the file after recompiling it.

  Byte-compiled files made with recent versions of Emacs (since 19.29)
will not load into older versions because the older versions don't
support this feature.  You can turn off this feature at compile time by
setting @code{byte-compile-dynamic-docstrings} to @code{nil}; then you
can compile files that will load into older Emacs versions.  You can do
this globally, or for one source file by specifying a file-local binding
for the variable.  One way to do that is by adding this string to the
file's first line:

@example
-*-byte-compile-dynamic-docstrings: nil;-*-
@end example

90105:7e3f621f1dd4

unless the file specifies otherwise.  This is so that compilation gives
results compatible with running the same file without compilation.
@xref{Loading Non-ASCII}.

  In general, any version of Emacs can run byte-compiled code produced
by recent earlier versions of Emacs, but the reverse is not true.

@vindex no-byte-compile
  If you do not want a Lisp file to be compiled, ever, put a file-local
variable binding for @code{no-byte-compile} into it, like this:

byte-compile.  Macro calls are expanded when they are compiled, so the
macros must already be defined for proper compilation.  For more
details, see @ref{Compiling Macros}.  If a program does not work the
same way when compiled as it does when interpreted, erroneous macro
definitions are one likely cause (@pxref{Problems with Macros}).
Inline (@code{defsubst}) functions are less troublesome; if you
compile a call to such a function before its definition is known, the
call will still work right, it will just run slower.

  Normally, compiling a file does not evaluate the file's contents or
load the file.  But it does execute any @code{require} calls at top
level in the file.  One way to ensure that necessary macro definitions
are available during compilation is to require the file that defines

  However, if you have built Emacs yourself and use it from the
directory where you built it, you will experience this problem
occasionally if you edit and recompile Lisp files.  When it happens, you
can cure the problem by reloading the file after recompiling it.

  You can turn off this feature at compile time by setting
@code{byte-compile-dynamic-docstrings} to @code{nil}; this is useful
mainly if you expect to change the file, and you want Emacs processes
that have already loaded it to keep working when the file changes.
You can do this globally, or for one source file by specifying a
file-local binding for the variable.  One way to do that is by adding
this string to the file's first line:

@example
-*-byte-compile-dynamic-docstrings: nil;-*-
@end example