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: Suppressing native compilation (short and long term) Date: Fri, 30 Sep 2022 19:02:17 +0300 Message-ID: <83wn9kdf5i.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <87v8p4kj3n.fsf@melete.silentflame.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27438"; mail-complaints-to="usenet@ciao.gmane.io" Cc: david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org, rlb@defaultvalue.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 30 18:09:17 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 1oeIZg-0006vV-So for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 18:09:17 +0200 Original-Received: from localhost ([::1]:46958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oeIZf-0007TJ-GZ for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 12:09:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeITD-0003nD-73 for emacs-devel@gnu.org; Fri, 30 Sep 2022 12:02:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51888) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeITC-0005YN-Hl; Fri, 30 Sep 2022 12:02:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AhicQBVAvycSlGG2j6LVtYe6j46AOu20jWCdAsMaKQI=; b=YVycSicrpBZf P/WudFJNJXCXr0h3+ylUA8J4DMTUhSaEQC4+oLMtMxCCWoKUikoc0wr2ADvEKmpiMqqpPlZ4wG6fO dfhiW/JxEQX8Jdqm2XN+uudqXpmOkZolmH+o0HLzsTusQp59IsFHeztT4zUcozEZok9alRnlXB5nW eRHhowNhdfsC/M5CCQNGbaioyyowX3vrKmsQXw/iBgu/EAvaq4PQ6OB3abkQpHeZ81BdzN0Qo82tD q0N2oJgdejMwSfZlW+EZktj3w/ZnJAYsgMMWw7sPEY281K8IIThRWzkWddTWM1vPUa211BGgJgQVd kXChDTTkKw2Nn2ObTyFAOg==; Original-Received: from [87.69.77.57] (port=2953 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 1oeITB-0000O6-Ot; Fri, 30 Sep 2022 12:02:34 -0400 In-Reply-To: <87v8p4kj3n.fsf@melete.silentflame.com> (message from Sean Whitton on Fri, 30 Sep 2022 07:55:08 -0700) 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:296526 Archived-At: > From: Sean Whitton > Cc: David Bremner , emacs-devel@gnu.org, akrl@sdf.org, > rlb@defaultvalue.org > Date: Fri, 30 Sep 2022 07:55:08 -0700 > > We currently bytecompile during package installation, and would like > also to do the native compilation at that time. > > The main reason for bytecompiling at package installation is that we > have logic to purge and recompile anything whose dependency versions > have changed, which means that all bytecode installed on Debian systems > was generated using known-correct macro definitions. Historically > ordinary Emacs processes running in non-batch mode have not guaranteed > this; I recall that the Org-mode developers discouraged use of ELPA to > install newer versions of Org because of these sorts of issues. This problem doesn't exist with *.eln files, because Emacs will regenerate new .eln files with different hashes in its name when the source file or the Emacs binary changes. So you do not have to trigger native compilation for these reasons. > A secondary reason is that it makes sense to compile once, system-wide, > rather than repeatedly in each user's home directory. I think this is misguided. If the user never loads a package, there's no reason to produce the *.eln files for it. At best it litters the disk with useless files. At worst, compilation could cause warnings or even errors, which are just an annoyance when the package is not going to be used for a long time, or not at all. These considerations are the reason why *.eln files are compiled JIT and on-demand. It is not a coincidence or lack of thought on our part, it is the result of considering many factors. I think you are trying to deal with *.eln files and with native-compilation in general as if it were a slightly different kind of byte-compilation. That is a mistake: it's a qualitatively different feature with different traits and different user-facing and administrator-facing aspects. > It is also nice that you can know everything is already in place > once your package is installed, so that I can unplug my laptop once > the package manager has exited, and I know that it isn't going to do > any CPU-intensive compilation and drain my battery. The *.eln files should not be part of "everything is in place", because they will be produced when needed. No user involvement or interaction is necessary.