From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Mon, 6 Jun 2022 12:23:49 -0400 Message-ID: References: <83o7z6849m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006e5f7f05e0c9e6e0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19714"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Andrea Corallo , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 06 18:59:58 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyG58-0004sc-Fy for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 18:59:58 +0200 Original-Received: from localhost ([::1]:56806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyG57-0008CD-Fi for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 12:59:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyFWQ-0007Pm-TO for emacs-devel@gnu.org; Mon, 06 Jun 2022 12:24:07 -0400 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:43890) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyFWP-00022d-8B; Mon, 06 Jun 2022 12:24:06 -0400 Original-Received: by mail-lf1-x131.google.com with SMTP id be31so24126985lfb.10; Mon, 06 Jun 2022 09:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zC49VThnoqC326uCDa8wlF78MOX891OUs5rjp5VgIic=; b=ctVGCgZGTkD1eMiBfuSZRw8JKTpZUdYft0bX7Z6CBmhvNaMFf2hjMSQ1T3cUKx7TKO FkvIfcMjJ4vcy+g3/tjJ4mx/bm1/Q6nhqGsKAW83qfAnriZqwR971tZZRz/TbeTQctsI kNBtP8gYS94EDPk4qrbuv9/oQUHVyO6C9CIS3bwbCQ4PZrJoMedW7vq0TnOb5OIfXOnn w/ZDjn2TJyZCyKKeBhNhITY16xcViJrWUyt0BRdQ1liTWg4WB046+GKyrSIOyFilEB5B 2QNTPp6jzhSmiI88ve6zfxBu2P/0gCzeLQay4XeLgU1ZlBeRoBlagkAbgFKOuA1IdbE3 m+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zC49VThnoqC326uCDa8wlF78MOX891OUs5rjp5VgIic=; b=g8DdaIme44r5Nhg7nbTxS1teugzFcuBwk+Sk7vECeWDT9+SMK4ckhOxfDZ2F5Sz0bw 9m8nmwcBie3YzTTkJqayukJ0ecgYrQIwDpp07hQ5vw/EaLkh8YdWlbpejLgfGHI6vSzM zHjwRM7LAid+ugw9KeaAOg+sK8rkP0aV9tI324mFGe/s7AevpbgYZJAedUu7CriPfd/9 WL9Fu5eU3CILzESNJqc/FTdvHDIwtkLa7uc05ymbLoWICX1sCoMixa6JkSZZr0dkFBHf eWryZHyiIF9v9SOz5jYbKmaOX9wwjNcwCLP8ciiZYUNG1y8hJQug4bVQEj7OkLc+WH0N PdAQ== X-Gm-Message-State: AOAM5338Cc/SeWh4Oke7g15NxjG1ml078e1tTlfGpcAkjfLQePhcgj0y GgADE3XscD/sj3SJqwnCY+8RTd0z07sfW17bImCDyEQ3 X-Google-Smtp-Source: ABdhPJxPLaDvqKNHoNT9QzTvAez1Xk8yzvgwQCdz0mTLs0opJrvWWyEHv8hRY3zVoPA8eKZKZLDP6nb0XT+i7d8/Wpc= X-Received: by 2002:a05:6512:1041:b0:478:afc6:5846 with SMTP id c1-20020a056512104100b00478afc65846mr15603848lfb.132.1654532642591; Mon, 06 Jun 2022 09:24:02 -0700 (PDT) In-Reply-To: <83o7z6849m.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=owinebar@gmail.com; helo=mail-lf1-x131.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 06 Jun 2022 12:58:30 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:290809 Archived-At: --0000000000006e5f7f05e0c9e6e0 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 6, 2022 at 6:39 AM Eli Zaretskii wrote: > > From: Stefan Monnier > > Cc: Andrea Corallo , emacs-devel@gnu.org > > Date: Mon, 06 Jun 2022 02:12:30 -0400 > > > > > That would explain the behavior I've seen. If that's the case, > shouldn't > > > batch-native-compile produce the byte-compiled file if it doesn't > exist? > > > > Sounds about right, tho maybe there's a good reason for the current > > behavior, I don't know. > > 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? 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? Lynn --0000000000006e5f7f05e0c9e6e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 6, 2022 at 6:39 AM Eli Zarets= kii <eliz@gnu.org> wrote:
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andrea Corallo <akrl@sdf.org>,=C2=A0 emacs-devel@gnu.org
> Date: Mon, 06 Jun 2022 02:12:30 -0400
>
> > That would explain the behavior I've seen.=C2=A0 If that'= s the case, shouldn't
> > batch-native-compile produce the byte-compiled file if it doesn&#= 39;t exist?
>
> Sounds about right, tho maybe there's a good reason for the curren= t
> behavior, I don't know.

Of course, there is: that function is what is invoked when building a
release tarball, where the *.elc files are already present.=C2=A0 See
lisp/Makefile.in.

That's what I exp= ected 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 uncon= ditionally.=C2=A0 Or perhaps
just note the possible hiccup in the= docstring for batch-native-compile?

However, sinc= e the eln file can be generated without the elc file, it also begs the ques= tion
of why the use of the eln file is conditioned on the existen= ce of the elc file in the
first place.=C2=A0 Are there situations= where the eln file would be incorrect to use=C2=A0
without the b= yte-compiled file in place?

Lynn


--0000000000006e5f7f05e0c9e6e0--