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 10:14:11 +0300 Message-ID: <83leph7e4c.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, larsi@gnus.org, liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 09:16:29 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 1ojbPI-0000pC-98 for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 09:16:28 +0200 Original-Received: from localhost ([::1]:37586 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojbPF-0007g4-UT for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 03:16:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojbNL-0006Vz-2W for emacs-devel@gnu.org; Sat, 15 Oct 2022 03:14:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44522) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojbNK-0007S9-6v; Sat, 15 Oct 2022 03:14:26 -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=hjW367/peAN4YDbL5nWTfotMOgSSsGT5Trg/Vuy8W2Q=; b=CshIrNFo7btV xglrq842k4rDH5YCXn+QyxYxMqjzPVT28SaexDGjMsJDEnzo8K8e9vNg36YPKH4ZWXDpMkGo/oqDA zjfDLUcQxn48ks3z1QXXGhmPM3lfaAqVk6B/QcRtr6T+HdVWHoGTbHzlPiBmIahASVzS65A5NBKM7 5j+hxUW1wmozqwi+WgaHUjC/EDg/2fK7F1eFv2mdDQydkUVBNugFOmMyOZVka3GXXL+XMPfA4WWw/ AdDcqyffmNo5JbByoLVffv53wQByAehgJD8JLOWpOeoyz56AKEKeRWdqEluGTHl7tzCjfYijliKJC k8AhslvraoYuFmhRdRY6JQ==; Original-Received: from [87.69.77.57] (port=4148 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 1ojbNJ-0002oz-BQ; Sat, 15 Oct 2022 03:14:25 -0400 In-Reply-To: (message from Stefan Monnier on Fri, 14 Oct 2022 23:14:41 -0400) 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:297760 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , Lars Ingebrigtsen , > liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel@gnu.org > Date: Fri, 14 Oct 2022 23:14:41 -0400 > > > 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? > 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.