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

[Pavel Fedin]

 Hello!

> Once again, please make this a run-time option, off by default,
> activated by a command-line argument.  Not a compile-time feature.
> Using spawn by default for Cygwin is a non-starter.

 Runtime ??? I am sorry, but what's the sense ?
 First, this will not work well, because many makefiles around call make
recursively. And they will not necessarily pass over command line options.
It is possible to modify make to do so, but this is horribly inconvenient.
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()
?
 Additionally your proposal would mean LOTS of changes. Instead of several
#ifdef's you would have both versions of code plus some extra conditions.
Why bloating up the code so much? spawn() is a full equivalent of fork() +
exec(). Even more, in Cygwin exec() and spawn() internally use the same
code. If exec() works, spawn() works too. BTW gcc on Cygwin uses spawn() for
running its components, and it works quite fine.

> Also, you are now modifying the EMX parts of the code, and I at least
> have no way of knowing whether those changes will work well for EMX.
> So please guard them with a Cygwin-specific conditional.

 The changes are:
 1. Rename 'status' to 'child_status'. Fixes error produced by new gcc,
because of nested 'status' declarations.
 2. Set environment to child's one before calling spawnvpe() and restore it
back after exit from child_execute_job().

 (1) is completely safe, it just fixes compile error. Nobody has hit this on
EMX because nobody has ever tried to use gcc 4.8 on EMX because OS/2 is long
dead. (2) should also be safe and at least harmless. Well, if you really
want it, changing child's environment can be #ifdef'ed. 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).

 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.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia