all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Lynn Winebarger <owinebar@gmail.com>
Cc: monnier@iro.umontreal.ca, akrl@sdf.org, emacs-devel@gnu.org
Subject: Re: native compilation units
Date: Tue, 07 Jun 2022 13:53:57 +0300	[thread overview]
Message-ID: <83tu8w7ni2.fsf@gnu.org> (raw)
In-Reply-To: <CAM=F=bDCpfSu3hsedB80f_8kQWLaFDWzHOHRG=Dymrt4BQ0+MA@mail.gmail.com> (message from Lynn Winebarger on Mon, 6 Jun 2022 22:14:00 -0400)

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



  reply	other threads:[~2022-06-07 10:53 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31  1:02 native compilation units Lynn Winebarger
2022-06-01 13:50 ` Andrea Corallo
2022-06-03 14:17   ` Lynn Winebarger
2022-06-03 16:05     ` Eli Zaretskii
     [not found]       ` <CAM=F=bDxxyHurxM_xdbb7XJtP8rdK16Cwp30ti52Ox4nv19J_w@mail.gmail.com>
2022-06-04  5:57         ` Eli Zaretskii
2022-06-05 13:53           ` Lynn Winebarger
2022-06-03 18:15     ` Stefan Monnier
2022-06-04  2:43       ` Lynn Winebarger
2022-06-04 14:32         ` Stefan Monnier
2022-06-05 12:16           ` Lynn Winebarger
2022-06-05 14:08             ` Lynn Winebarger
2022-06-05 14:46               ` Stefan Monnier
2022-06-05 14:20             ` Stefan Monnier
2022-06-06  4:12               ` Lynn Winebarger
2022-06-06  6:12                 ` Stefan Monnier
2022-06-06 10:39                   ` Eli Zaretskii
2022-06-06 16:23                     ` Lynn Winebarger
2022-06-06 16:58                       ` Eli Zaretskii
2022-06-07  2:14                         ` Lynn Winebarger
2022-06-07 10:53                           ` Eli Zaretskii [this message]
2022-06-06 16:13                   ` Lynn Winebarger
2022-06-07  2:39                     ` Lynn Winebarger
2022-06-07 11:50                       ` Stefan Monnier
2022-06-07 13:11                         ` Eli Zaretskii
2022-06-14  4:19               ` Lynn Winebarger
2022-06-14 12:23                 ` Stefan Monnier
2022-06-14 14:55                   ` Lynn Winebarger
2022-06-08  6:56           ` Andrea Corallo
2022-06-11 16:13             ` Lynn Winebarger
2022-06-11 16:37               ` Stefan Monnier
2022-06-11 17:49                 ` Lynn Winebarger
2022-06-11 20:34                   ` Stefan Monnier
2022-06-12 17:38                     ` Lynn Winebarger
2022-06-12 18:47                       ` Stefan Monnier
2022-06-13 16:33                         ` Lynn Winebarger
2022-06-13 17:15                           ` Stefan Monnier
2022-06-15  3:03                             ` Lynn Winebarger
2022-06-15 12:23                               ` Stefan Monnier
2022-06-19 17:52                                 ` Lynn Winebarger
2022-06-19 23:02                                   ` Stefan Monnier
2022-06-20  1:39                                     ` Lynn Winebarger
2022-06-20 12:14                                       ` Lynn Winebarger
2022-06-20 12:34                                       ` Lynn Winebarger
2022-06-25 18:12                                       ` Lynn Winebarger
2022-06-26 14:14                                         ` Lynn Winebarger
2022-06-08  6:46         ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tu8w7ni2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=akrl@sdf.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=owinebar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.