From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Building a tarball with native-compilation support Date: Thu, 05 Aug 2021 21:55:30 +0000 Message-ID: References: <83r1f8jtlu.fsf@gnu.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20689"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 05 23:56:35 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 1mBlLs-00056g-BD for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 23:56:32 +0200 Original-Received: from localhost ([::1]:40276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBlLq-00065r-MM for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 17:56:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBlL2-0005Lh-P5 for emacs-devel@gnu.org; Thu, 05 Aug 2021 17:55:40 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:65520) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBlL0-0007A9-UZ; Thu, 05 Aug 2021 17:55:40 -0400 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 175LtUZa002286 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 5 Aug 2021 21:55:30 GMT In-Reply-To: <83r1f8jtlu.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Aug 2021 09:25:33 +0300") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:272115 Archived-At: Eli Zaretskii writes: > I think we have an unsolved issue for when we will release an Emacs > tarball that supports native-compilation: how to compile the preloaded > *.el files natively at build time. This has to be done on the machine > where the tarball is built, because the *.eln files are > architecture-dependent, and thus cannot be in the source tarball. > > Currently, compiling the preloaded *.el into *.eln is a side effect of > byte-compilation, so a new .eln file is produced when the *.el file is > newer than the corresponding .elc file, which causes Make to invoke > the byte+native-compilation. But in a release tarball, all *.elc > files are newer than the corresponding *.el files, so this Make rule > will not be triggered, and the *.eln files will not be produced. So > Emacs will be dumped with byte-compiled *.elc files, which is not what > we want, I think. > > So unless I'm missing something, we need some Make wizardry to trigger > native-compilation at build time, even if the corresponding *.elc > files don't need to be re-generated. > > Comments? Hi Eli, IIUC in the release tarballs we precompile .el files but not the .c one as indeed this is arch specific. 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? Thanks Andrea