Re: native compilation units

[Eli Zaretskii <eliz@gnu.org>]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Mon, 6 Jun 2022 22:14:00 -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.

Because this function is for the case where producing *.elc files is
not wanted.

> 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

Because that function could be used in contexts other than building a
release tarball, and I see no need to restrict it.

And I don't think I understand the use case you want to support.
When is it useful to produce *.eln files for all the *.el files, but
*.elc files only for those *.el files that were modified or for which
*.elc doesn't exist?

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

Where do you see that requirement?