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: Sat, 15 Oct 2022 09:30:53 +0300 Message-ID: <83sfjp7g4i.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <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> <87fsfqi95f.fsf@trouble.defaultvalue.org> <83v8om6x8u.fsf@gnu.org> <87v8omgl4r.fsf@trouble.defaultvalue.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, larsi@gnus.org, akrl@sdf.org, monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 08:32:31 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 1ojaij-00012M-Op for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 08:32:29 +0200 Original-Received: from localhost ([::1]:58648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojaii-0006Xs-8h for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 02:32:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59388) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojahQ-0005sR-TV for emacs-devel@gnu.org; Sat, 15 Oct 2022 02:31:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35148) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojahO-00028l-K1; Sat, 15 Oct 2022 02:31:06 -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=+RTmdpnR0Knt2d+FFlgWyQNFN34fbyDD3vH7EbpF6ZA=; b=ACIxlAx+d2at LhlVnjoFKhHfU9A6wS+mMqmbfieiobo/sOum7qkK96If6eekUSsVtKrZzuGJCt2bJCP4G6U4+66jT MRnUi6p/pvse9YCcudWWahSxKVks06j6fw1sgUptytdZZi2YzI+/imDK4Wd/FpLQnuzKlS6XYOPvl 75Cs2iF1P4qhgMTYBRJ8BZWYii+GNqheYfNuxkwiJAWYy81ATY+iNM5RqstM+9erqd8ytN5NjFFgi ziT4RJ1qYURoxBllAXOPsuqPzclH9XKvG+HNtRCBzr95rQeiQhZirdx9vVdtQIObOzYdApeCTKUCi AF4D9koJ1dd8crwfwLfX9Q==; Original-Received: from [87.69.77.57] (port=1522 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 1ojahO-0000yl-1p; Sat, 15 Oct 2022 02:31:06 -0400 In-Reply-To: <87v8omgl4r.fsf@trouble.defaultvalue.org> (message from Rob Browning on Fri, 14 Oct 2022 16:17:56 -0500) 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:297758 Archived-At: > From: Rob Browning > Cc: luangruo@yahoo.com, larsi@gnus.org, akrl@sdf.org, > monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org > Date: Fri, 14 Oct 2022 16:17:56 -0500 > > Eli Zaretskii writes: > > >> From: Rob Browning > > >> - 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. > > > > This should work for preventing the native-compilation from storing > > the *.eln files. If it doesn't work for you, please tell the details, > > and we will investigate. > > Hmm, which "this" did you mean? If you meant HOME=/does-not-exist, I > thought people had already said that wouldn't work because the attempt > to build trampolines would still cause a crash. But I may well have > misunderstood. I meant HOME=/does-not-exist, yes. If that doesn't work (but please test), we should fix that, I think. Please report your findings if that doesn't work. We use that in our own test suite. > > One other way is to change the value of native-comp-eln-load-path. I > > hesitate to add an environment variable for that, because environment > > variables are inherited to subprocesses, and so setting a variable for > > some Emacs process will affect all of its Emacs subprocesses. This > > was found to be a reason of tricky and hard-to-debug problems when > > users set EMACSLOADPATH like that, and I presume the same can easily > > happen with the equivalent variable for *.eln files. So I'd rather > > not add such a variable unless we find a very good reason. > > For what it's worth, the reason we'd been at least a bit inclined that > direction is because if you have hundreds of emacs add-on packages > (which I believe we do in Debian), and they all have build and or test > suites that vary in any way they like, it could be much more difficult > to track down all of the emacs invocations in each project's source to > add some argument than it would be to just export an environment > variable before running the suite. I understand, but don't you have some kind of centralized script or group of scripts that runs the testing? In that case, you could make the Emacs command, or its template, be part of those few scripts, and then the change will be less painful. Please understand my POV: adding an environment variable affects all Emacs users, not just distros that have testing suites. There's much more at stake than your particular testing needs, and many Emacs users know much less about the potential effects of such environment variables than you and me. > I suppose we could just shadow emacs in the path with a wrapper that > includes the argument(s), assuming few of the projects have their own > interfering options, and that they always use the same (or a handful of > predictable) relative invocation of emacs, e.g. "emacs" not > "/usr/bin/emacs" or... Yes, something like that. At least that's what we do in the Emacs's own test suite (which, of course, is much smaller than yours). > > With respect to writing the *.eln files, Emacs will look along > > native-comp-eln-load-path for the first directory that is writable, > > and use that. So you could at least partially handle this case by > > making sure native-comp-eln-load-path includes at least one writable > > directory. > > Right, though we also have to make sure we can do that sufficiently > early in *every* case. Yes, ideally from the same/similar wrapper script that actually invokes Emacs, via the --eval option.