From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 15 Oct 2022 10:00:14 -0400 Message-ID: References: <87ill8paw7.fsf@trouble.defaultvalue.org> <83o7uzivey.fsf@gnu.org> <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> <835ygob7ja.fsf@gnu.org> <8335bra2rl.fsf@gnu.org> <87ilkncugg.fsf@gnus.org> <83zgdz7x8u.fsf@gnu.org> <83leph7e4c.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="18435"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: akrl@sdf.org, larsi@gnus.org, liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 16:01:59 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 1ojhjj-0004ZH-2l for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 16:01:59 +0200 Original-Received: from localhost ([::1]:58030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojhjh-0001wm-PL for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 10:01:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojhiE-00018D-Pz for emacs-devel@gnu.org; Sat, 15 Oct 2022 10:00:28 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8262) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojhiB-0000nd-LU; Sat, 15 Oct 2022 10:00:25 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BE2844407A4; Sat, 15 Oct 2022 10:00:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 016DF4407EC; Sat, 15 Oct 2022 10:00:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665842416; bh=ddBk2ubnfYEmva3sckJV/bt5O4Vbne1fNIeHMaaLVVk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mArYCtuj8a20T/MMxySPUQAKlaI3wSwkM450+ANRv3yG8yKUCV1cEK/kus6htlDgO Oj0eSZaA/QCIvo/cGcp9bI7JPhV9DUKrjnfoX04LRZtbjThQG+29e/SVQkseGOJlCP lQegryszDAreY3XucQTTkuVdYyCRF+Y4NlK6Tp1SraOxvXKUblOR2px+uTJF6XuLmR pR5yBOhLxH5IqfkpCFO0+fgNRPEcWhQu6AAQhbPZM6XIPS2Kee7WLV6qSyZugzOxG8 m3iKBvYn7qEJW3ZJKZ3pGX+lDZWZUvKERtZK6e2NY2UowPHPUQqCM6sdJiHJbeUCU1 KTcsgGUvyyG7Q== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B66D6120EED; Sat, 15 Oct 2022 10:00:15 -0400 (EDT) In-Reply-To: <83leph7e4c.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Oct 2022 10:14:11 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:297776 Archived-At: >> > Dumb question: can't we just run the spawned compilation processes with >> > --no-site-file? >> For trampolines, I guess that should work since they shouldn't depend on >> local customizations. > But it will potentially cause other issues, because the environment in > which the compiling Emacs sub-process run is different from that of > the Emacs session which triggered the compilation? So we could have > warnings and errors in the compilation process due to stuff being > undefined etc.? Isn't this why we do read the init files in the async > sub-process which performs the compilation? Yes, when compiling actual ELisp files. I'm talking about compiling the trampolines: that's different because it's just compiling a fixed chunk of code *we* write. >> Of course, a tempting alternative is to resort to >> "binary hacking", i.e. compile *one* template-trampoline and then >> generate all every other trampoline by copying that template and >> patching the right "stuff" into it. That would save us from running the >> compiler to generate the trampolines (i.e. it would let us behave >> correctly on Windows even when GCC/libgccjit is not found at run time), >> but it would force us to write architecture-dependent code to patch the >> binary template. > > I don't think we should depend on architecture-dependent code. It > would mean we don't support new platforms until someone writes such > code for them, for starters. It's against our development tendencies > for the past 10 years at least. I know, I know. From a technical point of view, it's The Right Thing to do, I think, tho: it will eliminate all the other issues surrounding trampolines (e.g. disk space to store trampolines, dependence on libgccjit for the creation of those trampolines, fork bombs) and will be much more efficient both in CPU time and memory use (we don't care too much, because trampolines are hopefully not too frequents, so we live with them being quite inefficient in the time to create them (and set them up, via dyn-linking) and in their memory use). But yes, the architecture-dependence is a serious problem, which is why we've so far avoided that solution. Stefan