From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Fri, 14 Oct 2022 12:53:48 -0500 Message-ID: <87fsfqi95f.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <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> <83edvqyr3q.fsf@gnu.org> <874jwl8e4p.fsf@gnus.org> <87pmf64beo.fsf@gnus.org> <87h70i4a46.fsf@gnus.org> <83tu4irzl1.fsf@gnu.org> <87y1ttsrve.fsf@yahoo.com> <83r0zlqxcr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21898"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, akrl@sdf.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org To: Eli Zaretskii , Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 14 19:58:19 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 1ojOwt-0005VL-Pa for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 19:58:19 +0200 Original-Received: from localhost ([::1]:43692 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojOws-0000mI-Lb for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 13:58:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojOsa-0003eZ-Ut for emacs-devel@gnu.org; Fri, 14 Oct 2022 13:53:52 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37488) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojOsZ-0001p5-4R; Fri, 14 Oct 2022 13:53:52 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id A6BCF200F5; Fri, 14 Oct 2022 12:53:48 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 3681014E081; Fri, 14 Oct 2022 12:53:48 -0500 (CDT) In-Reply-To: <83r0zlqxcr.fsf@gnu.org> Received-SPF: pass client-ip=45.33.119.55; envelope-from=rlb@defaultvalue.org; helo=defaultvalue.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.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:297726 Archived-At: Eli Zaretskii writes: > I'm still discussing with Rob his needs. I hope to eventually > understand their needs. For now my only conclusion is that they need > to tweak native-comp-eln-load-path in some situations, to control > where the *.eln files are deposited. Which is easy and supported > already, AFAIU. Eli, Lars, Andrea, and others, I think I'm mostly caught back up with this thread, and hope to summarize a few things here: - I made a mistake in emphasizing (via the thread subject) a particular "solution" (suppressing native compilation). In the end, from the Debian perspective, for the most immedate issue, we don't need that particular solution (and I wasn't actually set on it at the time). I'd mostly started there because it's *a* possible solution, and one I'd imagined might be easyish to implement (clearly that was naive). But other solutions would be fine too. - For example, redirecting all incidental writes away from HOME would be fine too. - We'd prefer to still be able to set HOME=/does-not-exist, which I assume would mean that we'd need some other way to redirect *all* of the eln file writes (including trampolines). Our practice of setting HOME to a nonexistent directory during some packaging operations allows us to detect unexpected, and erroneous attempts to write to HOME during those processes. - If we are going to have "some other way" to redirect the eln files, then for us an environment variable might be easier, so that we can just export it before we start the relevant build/test/etc. and then it'll affect all invocations of emacs in that environment. I suspect an environment variable might also make it easier to establish the setting "early enough" in the emacs startup process, but don't know that. - If just setting HOME will do the job, and there's no interest here in anything further, then we can probably just do that, or if we ended up needing to, we could likely add our own DEBIAN_... environment variable, and carry a patch, but of course that's less desirable. - As an aside, I suspect Emacs may eventually want to have some way to restore the ability to tolerate an unwritable filesystem. I have more than once in the past launched emacs from an emergency shell to fix a broken host where the filesystem was read-only and /home might not be mounted (and if it were on NFS and there's no network yet, could not be). I'd much rather use emacs there, than /usr/bin/sensible-editor. Of course now I know that I could just set HOME=/tmp and proceed, but will others? Might at least be worth making sure any error messages would lead people to that option. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4