GNU bug report logs - #58509
29.0.50; Synchronous nativecomp

Previous Next

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 11:06:31 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: larsi <at> gnus.org, 58509 <at> debbugs.gnu.org
> Date: Thu, 20 Oct 2022 07:23:55 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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
> 
> We invoke a sync compilation for trampolines (but I think it's not
> relevant here)
> 
> > 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?
> 
> Okay so IIUC your suggestion would be to: when we identify '--batch' we
> search for a signature in the commandline to identify the trampoline
> compilation and set in case `comp-no-spawn'?

Yes.  And if that works, my next question is: can we then remove the
new -no-comp-spawn command-line option, or do we need it for some
other cases?

Previous Next

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