Re: native compilation units

[Lynn Winebarger]

On Mon, Jun 6, 2022 at 12:58 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Mon, 6 Jun 2022 12:23:49 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Andrea Corallo <akrl@sdf.org>, emacs-devel@gnu.org
>
>  Of course, there is: that function is what is invoked when building a
>  release tarball, where the *.elc files are already present.  See
>  lisp/Makefile.in.
>
> That's what I expected was the case, but the question is whether it "should"
> check for those .elc files and create them only if they do not exist, as opposed
> to batch-byte+native-compile, which creates both unconditionally.  Or perhaps
> just note the possible hiccup in the docstring for batch-native-compile?

You are describing a different function.  batch-native-compile was
explicitly written to support the build of a release tarball, where
the *.elc files are always present, and regenerating them is just a
waste of cycles, and also runs the risk of creating a .elc file that
is not fully functional, due to some peculiarity of the platform or
the build environment.

Ok - I'm not sure why only generating the .elc in the case that it does not already exist is inconsistent with the restriction you describe.

Ignoring that, according to https://github.com/emacs-mirror/emacs/blob/master/lisp/emacs-lisp/comp.el the signature and docstring are:

	(defun batch-native-compile (&optional for-tarball) "Perform batch native compilation of remaining command-line arguments.
	Native compilation equivalent of `batch-byte-compile'.
	Use this from the command line, with `-batch'; it won't work
	in an interactive Emacs session.
	Optional argument FOR-TARBALL non-nil means the file being compiled
	as part of building the source tarball, in which case the .eln file
	will be placed under the native-lisp/ directory (actually, in the
	last directory in `native-comp-eln-load-path')."

If the restriction you describe is the intent, why not 

(1) make "for-tarball" non-optional and remove that argument, and

(2) put that intent in the documentation so we would know not to use it

 

> However, since the eln file can be generated without the elc file, it also begs the question
> of why the use of the eln file is conditioned on the existence of the elc file in the
> first place.  Are there situations where the eln file would be incorrect to use
> without the byte-compiled file in place?

Andrea was asked this question several times and explained his design,
you can find it in the archives.  Basically, native compilation is
driven by byte compilation, and is a kind of side effect of it.

I understood that already - the question was why the .elc file, as an artifact, was required to exist in addition to the .eln file.

I did follow your (implied?) suggestion and went back through the archives for 2021 and 2020 and saw some relevant discussions.

The last relevant post I saw was from Andrea indicating he thought it shouldn't be required, but then it was just dropped:

https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00561.html

I have an experimental branch where the .elc are not produced at all by

make bootstrap. The only complication is that for the Emacs build I had

to modify the process to depose files containing the doc so

make-docfile.c can eat those instead of the .elc files. Other than that

we should re-add .eln to load-suffixes. But as I'm not sure this is a

requirement I'd prefer first to converge with the current setup. Unless

I get some specific input on that I think I'll keep this idea and its

branch aside for now :)

I may have missed a relevant subsequent post.

Lynn