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