[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christopher Faylor
Subject: Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated
Date: Fri, 16 Aug 2013 15:05:36 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Aug 16, 2013 at 02:18:31PM -0400, Paul Smith wrote:
>On Fri, 2013-08-16 at 13:30 -0400, Christopher Faylor wrote:
>> On Fri, Aug 16, 2013 at 01:12:28PM -0400, Paul Smith wrote:
>> >On Fri, 2013-08-16 at 20:59 +0400, Pavel Fedin wrote:
>> >>Friday, August 16, 2013, 19:19:58 you wrote:
>> >>
>> >>>Also, when I'm making changes to the exec() code I don't spend a lot of
>> >>>time worrying about spawn() so it is possible that it will be broken
>> >>>from time to time and, in fact, I think you actually noticed some
>> >>>breakage in the cygwin list.
>> >>
>> >>Which one ?
>> >
>> >It seems that the discussion is not directly addressing the issue here.
>> >Personally I don't worry that spawn() will break, and I wouldn't mind a
>> >more performant version of make for windows/cygwin, either optionally
>> >or by default.
>> You may not be concerned on whether spawn() in Cygwin actually works
>> right or not but I am.  If this becomes the default option for Cygwin I
>> will definitely figure out how to turn it off for the Cygwin release,
>> just like I'm not allowing MS-DOS paths in the released version of
>> Cygwin's make.
>Sorry, I was too flippant here.  What I would like, in the abstract, is
>that if you download the GNU make tarball from the GNU site and run
>"./configure" and build in a Cygwin environment, the resulting
>executable has the same features you'd get if you downloaded the binary
>version of GNU make with the official Cygwin distribution.  As far as
>I'm concerned, you (Christopher) know best and have final say as to what
>that configuration is, and I have little interest in getting involved in
>I'm willing to entertain the idea of configure options that allow for
>alternate behaviors, that people could get by performing their own
>builds.  I have no exact criteria for what I would agree to, but in
>general it would have to be of significant utility to a significant
>number of people, and it can't be too ugly or difficult to maintain.
>I'm much less enthused about runtime flags, but I don't like to take
>anything completely off the table... yet.

Thanks for clarifying.

>> >So, the question is very simple: is it technically possible to ensure
>> >that the operations make takes today in the child between fork and exec
>> >can be handled properly in a spawn-based implementation?
>> This is, IMO, just a variation of the same question that Eli raised.
>Perhaps: I haven't gone back and re-read the whole thread.  In any event
>I don't recall anyone (Pavel) specifically answering it.  That's what
>I'm waiting for: the results of an investigation as to what works and
>what doesn't, based on examination of the code rather than anecdotal
>evidence ("works for me").

I think what we keep hearing is the usual from people who provide
patches: "It works!  I've tried it!"

>> Presumably make works at least 99% correctly on Windows using spawn*().
>> I don't doubt at all that the patch actually works great with most uses
>> of make in Cygwin.  However, I would rather be 100% correct and slower
>> than 99% correct with head scratching corner case errors.
>Exactly, hence the reason for my question.  I'm not interested in adding
>this if, when it's enabled, things don't work correctly.
>On the other hand I'm not sure it's not possible to get things working
>correctly.  Or, perhaps it's possible to make them work correctly if we
>disable some (already optional) features: then the configuration of this
>alternate mode should disable those as well.

Violent agreement.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]