From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Building a tarball with native-compilation support Date: Fri, 06 Aug 2021 09:05:02 +0300 Message-ID: <83wnozhzw1.fsf@gnu.org> References: <83r1f8jtlu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3437"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 06 08:05:42 2021 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 1mBszG-0000gY-20 for ged-emacs-devel@m.gmane-mx.org; Fri, 06 Aug 2021 08:05:42 +0200 Original-Received: from localhost ([::1]:58486 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBszE-0003GK-4t for ged-emacs-devel@m.gmane-mx.org; Fri, 06 Aug 2021 02:05:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBsyb-0002Xz-KX for emacs-devel@gnu.org; Fri, 06 Aug 2021 02:05:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37728) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBsyb-00088p-5M; Fri, 06 Aug 2021 02:05:01 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1703 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBsya-0000zH-P1; Fri, 06 Aug 2021 02:05:01 -0400 In-Reply-To: (message from Andrea Corallo on Thu, 05 Aug 2021 21:55:30 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:272124 Archived-At: > From: Andrea Corallo > Cc: Lars Ingebrigtsen , emacs-devel@gnu.org > Date: Thu, 05 Aug 2021 21:55:30 +0000 > > IIUC in the release tarballs we precompile .el files but not the .c one > as indeed this is arch specific. That's correct. > Now I'm asking my self: > > - given that as you mentioned the .eln will have to be produced in the > target machine > - given that producing .eln can produce at the same > time also the corresponding .elc > > Does it make sense to still precompile and distribute the .elc files to > the users? The reason for that is to keep one single release tarball > that can serve native and non native builds or there are other reasons? Yes, there are valid reasons to have the *.elc files in the tarball: . They make the build faster, because the step of using only *.el for COMPILE_FIRST is avoided; . They are a must if the user wants Emacs without native-compilation support, and in that case make the build extremely fast; . They provide canonical *.elc files produce on a system where most of the *.el files can be meaningfully byte-compiled because the related functionality is supported. I think if we come up with a way to perform only the native-compilation of a .el file when the corresponding .elc already exists, the build will also faster, because we will use the byte-compiled comp.elc and comp-cstr.elc, not the *.el files. So I think we should work in this direction, and not decide to work around the issue by omitting *.elc from the tarball. How about if we start by providing a separate Makefile target to native-compile a single .el file when its .elc exists and is up-to-date?