bug#58509: 29.0.50; Synchronous nativecomp

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, 58509@debbugs.gnu.org
>> Date: Sun, 23 Oct 2022 10:51:14 +0000
>> 
>> Eli Zaretskii <eliz@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