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: Sun, 02 Oct 2022 22:15:21 +0300 Message-ID: <83edvqyr3q.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.fsf@gnu.org> <87mtafnun5.fsf@trouble.defaultvalue.org> <83sfk6ahty.fsf@gnu.org> <8735c6b0wo.fsf@gnus.org> <87y1ty9lha.fsf@gnus.org> <87lepym6ok.fsf@trouble.defaultvalue.org> <877d1i9h7k.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rlb@defaultvalue.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 21:16:11 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 1of4Rf-0001i2-JN for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 21:16:11 +0200 Original-Received: from localhost ([::1]:52780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of4Re-0008NQ-BY for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 15:16:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of4R1-0007cs-Ty for emacs-devel@gnu.org; Sun, 02 Oct 2022 15:15:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35462) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of4R0-0004mL-Rh; Sun, 02 Oct 2022 15:15:30 -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=zqlOsGy2G1S0TlTHE8MBfZOkv6bYABcND11FJIVBokY=; b=mN+K1rsuvRSB osOE3ZHjk4IKzi1aQHtO0cPJu1+c4KEhOa7nI034KRUVvfhznamCDu4c/Pg6KSUjPdslQVF4nFmD5 MsZGosnVNkBrI1TAxm03AGMe6cYh5rfWQRIe0SEH0GoHVXrBckScg3QmWVFeag3Nj0HbmHCaofUPQ OrIORo4bgcMJ4Jp8SPWPacR4RFnTsk2p/h9VNWQgrkc/mr1EBXsSn5AOhbRJHktdGI9tW0XeMxY/9 lwKeypBT7bGJVXKaN1R3xvEG7BErrwP2gWG4K8Y4WC86mGgN4PPmg0NTiLZrOaJSGaG2PVju7kiB4 liu626uQFGBakKtvKyecnw==; Original-Received: from [87.69.77.57] (port=2929 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 1of4Qz-0005Zo-So; Sun, 02 Oct 2022 15:15:30 -0400 In-Reply-To: <877d1i9h7k.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 02 Oct 2022 21:08:15 +0200) 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:296695 Archived-At: > From: Lars Ingebrigtsen > Cc: Stefan Monnier , Eli Zaretskii > , david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org > Date: Sun, 02 Oct 2022 21:08:15 +0200 > > Rob Browning writes: > > > At the top level, we wanted a way to avoid writing to HOME during > > packaging, testing, installs (in this case, it's the .eln files, now > > that we've enabled native compilation). > > > > That could be handled by some way to turn off native compilation, or by > > some way to comprehensively divert those writes to another location > > (e.g. temp dir). Either is fine, though we'd originally thought the > > former might make things a bit easier. > > Yeah, I think the former is both easier to implement and easier for > users. The request that started this discussion was not from users, it was from distributors. If we want to consider providing (yet another) user option for disabling native compilation, then we should: . understand why and in which situations they may need it . what exactly needs to be disabled (e.g.: do you want to disable loading the existing *.eln files?) . understand why the existing options don't already provide solutions I object to introducing new options before we do the above and understand well what we are talking about. > So I'm thinking of introducing a user option like > `native-compile-inhibit', which will make Emacs skip the native-comp > machinery when loading .elc files. It will default to nil, of course, > but perhaps it would be convenient to make it depend on an environment > variable like "NATIVE_COMPILE_INHIBIT"? Then users (and the Debian > build system) could say "NATIVE_COMPILE_INHIBIT=true emacs ..." when > doing testing etc? Would that fit your use case? Their use case is not the use case of Emacs users.