GNU bug report logs - #58509
29.0.50; Synchronous nativecomp

Previous Next

Package: emacs;

Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>

Date: Fri, 14 Oct 2022 10:39:02 UTC

Severity: normal

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: larsi <at> gnus.org, 58509 <at> debbugs.gnu.org
Subject: bug#58509: 29.0.50; Synchronous nativecomp
Date: Thu, 20 Oct 2022 09:43:21 +0300
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: larsi <at> gnus.org, 58509 <at> debbugs.gnu.org
> Date: Wed, 19 Oct 2022 19:31:05 +0000
> 
> > "do it always for trampolines in the --batch invocations"
> 
> So you mean identifying that we are doing a trampoline compilation and
> disable the native compiler without a specific flag?

Yes, but only in -batch sessions.

I believe this is our logic now: if we are going to compile a
trampoline, we invoke an async subprocess with both -batch and
the -no-comp-spawn options.  But if the --batch session can figure
out that it's compiling a trampoline, it can automatically behave as
if -no-comp-spawn was passed on the command line, no?

> -no-comp-spawn makes sure that in the spawend compilation processes, no
>  matter what, we never spawn again other compilation processes.
> 
> We have two invocations for spawning processes, one for sync
> compilations and one of async (none of the invocation is specific to
> trampolines).  This patch is using -no-comp-spawn for both.

I'm asking why compilation of trampolines could behave like that
automatically, when the compilation is done in a -batch invocation.

Thanks.




This bug report was last modified 2 years and 233 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.