GNU bug report logs - #58509
29.0.50; Synchronous nativecomp

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 58509 <at> debbugs.gnu.org
Subject: bug#58509: 29.0.50; Synchronous nativecomp
Date: Sun, 23 Oct 2022 12:10:20 +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: Sun, 23 Oct 2022 10:51:14 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> 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?
>> 
>> If it works I think it should be equivalent at that point.  But at the
>> moment is not so trivial to identify this condition as we have no clear
>> marker of it.
>> 
>> The current invocation for compilations is just like:
>> 
>> emacs --batch -l sometmpfile.el
>> 
>> I don't know if we have some other option for adding a marker other than
>> the most obvious (the dedicated flag).
>
> At some point during compilation, we surely know that we are compiling
> a trampoline, right?  So I thought to avoid forking at that point, so
> that we don't need yet another command-line option for internal
> purposes.

That's correct, but I believe the issue is that when we realize we are
compiling a trampoline it's too late, and we might have been decided
already a new trampoline needs to be compiled and installed.  The
parsing of the command line args happens way earlier and that's why this
technique works at solving this issue.

  Andrea

Previous Next

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