Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

[Eli Zaretskii]

> From: Pavel Fedin <address@hidden>
> Cc: address@hidden
> Date: Tue, 06 Aug 2013 10:46:51 +0400
> 
>  Runtime ??? I am sorry, but what's the sense ?

I tried to explain that in my first response: 'fork' has a certain
semantics and implements requirements that 'spawn' does not.  Since
Cygwin is a Posix environment and runs the Posix code in Make, users
generally expect it to follow the Posix semantics to the letter.
'spawn' will not in general do that 100%, although it is probably
close, at least in this case.

IOW, the default operation mode should always work correctly.  If it
is possible to speed it up without losing correctness, fine.
Otherwise, the fast version must be optional, and the option must be
selectable at run time, or else users will be unable to decidewhat
they want, unless they also build their own Make.

>  First, this will not work well, because many makefiles around call make
> recursively. And they will not necessarily pass over command line options.

Using "$(MAKE) $(MFLAGS)" is good practice that is seen in many
places.  We can expect that from users who want to invoke Make with a
non-default option.

> Well, it would be a little more convenient to have env variable, something
> like MAKE_USE_SPAWN, but anyway, what is the real purpose of keeping fork()
> ?

Environment variable would probably also be OK, if Chris agrees.

As for the purpose, see above: there must be a way for users to
request 100% correct, if slower, operation mode.

>  Additionally your proposal would mean LOTS of changes. Instead of several
> #ifdef's you would have both versions of code plus some extra conditions.

I realize that it is easier to use compile-time conditions, but I
don't think this will be acceptable.

> spawn() is a full equivalent of fork() + exec().

I'm not sure (Chris?).  In any case, you will see in the code that
Make does a few things between the calls to 'fork' and 'exec'.  How
can you be sure that 'spawn' does all that in exactly the same way?
And even if does that today, how can anyone be sure the Cygwin
maintainers will not change it one day to do things in a slightly
different way?

> gcc on Cygwin uses spawn() for running its components, and it works
> quite fine.

GCC and Make don't do the same and don't have the same code that deals
with subprocesses.  That this works in GCC is not in any way proof
that it will work in Make exactly like 'fork' does.

> (2) should also be safe and at least harmless.

I just don't know, and don't have EMX installed to test that.

> Well, if you really want it, changing child's environment can be
> #ifdef'ed.

Yes, please.

> However according to specification, spawnvpe() looks for the binary
> in current PATH, so on EMX the same thing should apply as on
> Cygwin. Well, it could work if EMX doesn't strictly follow POSIX
> semantics and implicitly considers current directory to be part of
> PATH (DOS/Windows-style behavior).

EMX is not a Posix environment, AFAIK.  And in any case, I don't want
to risk breaking a platform for which I'm not responsible and whose
functionality I cannot test.  I'm sure you understand.

>  OK, if you really-really don't care about what someone other than you
> think, can you accept last chunk of the patch for now (variable rename) ?
> This would decrease size of speedup patch which i will have to maintain.

You mean, rename 'status" to 'child_status'?  That's not a problem.