On Thu, Aug 22, 2013 at 05:48:21PM +0300, Eli Zaretskii wrote:
>> From: Pavel Fedin
>> Date: Thu, 22 Aug 2013 09:43:09 +0400
>> Cc: bug-make@gnu.org
>>
>> What if we implement posix_spawn() for Cygwin ? Would you like
>> that ?
>
>If Paul accepts that for platforms other than Cygwin, I certainly
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, Augus
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 wi
On Wed, Aug 07, 2013 at 04:38:22PM +0300, Eli Zaretskii wrote:
>> From: Pavel Fedin
>> Cc: m...@cgf.cx, bug-make@gnu.org
>> Date: Wed, 07 Aug 2013 10:22:31 +0400
>>
>> > > 2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'.
>> >
>> > This is true, but how is this relevant to the i
On Wed, Aug 07, 2013 at 12:52:48PM +0400, Pavel Fedin wrote:
>> I tried to explain that in my first response: 'fork' has a certain
>> semantics and implements requirements that 'spawn' does not.
>
>Stop stop stop... Just to avoid misunderstanding here... fork() alone
>cannot be replaced with spaw
On Wed, Aug 07, 2013 at 04:38:22PM +0300, Eli Zaretskii wrote:
>> From: Pavel Fedin
>> Cc: m...@cgf.cx, bug-make@gnu.org
>> Date: Wed, 07 Aug 2013 10:22:31 +0400
>>
>> > > 2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'.
>> >
>> > This is true, but how is this relevant to the i
[Reply-to set to bug-make]
On Mon, Aug 05, 2013 at 09:19:18AM +0400, Pavel Fedin wrote:
> Hello!
>
>> Right. Because I knew I could just turn if off for the Cygwin release.
>> There is no reason to nuke the feature for people who want to roll
>> their own version of make with DOS paths turned on.
On Sat, Aug 03, 2013 at 11:16:44AM +0300, Eli Zaretskii wrote:
>> Date: Fri, 2 Aug 2013 22:49:31 -0400
>> From: Christopher Faylor
>>
>> On Tue, Jul 30, 2013 at 08:02:54PM +0300, Eli Zaretskii wrote:
>> >> Date: Tue, 30 Jul 2013 11:52:58 -0500
>> >&g
On Wed, Jul 31, 2013 at 10:11:40AM -0400, Paul Smith wrote:
>On Wed, 2013-07-31 at 10:37 +0400, Pavel Fedin wrote:
>>Looks like, if you want DOS paths, and running under Cygwin, an
>>explicit conversion has to be performed on getcwd() result using
>>cygwin_conv_path(). However i did not test this
On Tue, Jul 30, 2013 at 07:41:19PM +0300, Eli Zaretskii wrote:
>> Cc: bug-make@gnu.org, Pavel Fedin
>> From: Roland Schwingel
>> Date: Tue, 30 Jul 2013 18:29:07 +0200
>>
>> I clearly think the DOS paths mode should remain in even for cygwin. I
>> know that there are objections in cygwins top le
On Wed, Jul 31, 2013 at 09:47:27AM +0400, Pavel Fedin wrote:
> Hello!
>
>> Can you at least tell when (year and month) this discussion took place?
>
> I was able to find only this in ML archive:
>http://cygwin.com/ml/cygwin/2013-01/msg00113.html
> The rest of discussion was held in private email. F
On Tue, Jul 30, 2013 at 08:02:54PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 30 Jul 2013 11:52:58 -0500
>> From: Norbert Thiebaud
>> Cc: Pavel Fedin , bug-make@gnu.org
>>
>> fork() is a very expensive operation in cygwin.
>
>Yes, I know. But without it, some things that are expected of a Posix
>
On Tue, Jul 30, 2013 at 02:42:23PM +0400, Pavel Fedin wrote:
> Hello!
>
> Please take this patch, Cygwin team told that they would like to integrate
>with upstream. I have already posted it some time ago but got no reply.
> The patch significantly improves performance of Make under Cygwin.
Actuall
On Mon, Oct 15, 2007 at 05:11:19PM -0400, Paul Smith wrote:
>On Mon, 2007-10-15 at 13:36 -0700, Howard Chu wrote:
>> IMO the objections to requiring MSYS/Cygwin on Windows made no sense
>> in this discussion. "Make" is inherently a POSIX command line tool.
>> Anybody using it on Windows needs a POS
On Sat, Oct 13, 2007 at 10:22:56PM +0200, Ram??n Garc??a wrote:
>In my opinion, distributed control version systems like GIT or
>Mercurial are the way to go in the long term. In Sun all the
>repositories are (or are being migrated to) Mercurial.
>
>There is only one serious limitation with GIT: ea
On Sat, Oct 13, 2007 at 12:37:46PM -0400, Paul Smith wrote:
>Hi all;
>
>I'm considering switching from CVS to another form of SCM. Currently,
>Savannah supports (in addition to CVS) GNU arch and GIT. If SVN were
>supported I'd probably go for that, because (a) it has great support for
>alternativ
On Sat, Aug 04, 2007 at 01:08:54AM +0300, Eli Zaretskii wrote:
>> Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT)
>> From: [EMAIL PROTECTED]
>>
>> oops, here is the attached console capture
>
>It's much better to send this as plain text (you can capture it with
>`tee' or even by copying and pasting the
On Sun, Jan 28, 2007 at 05:06:50PM -0500, Paul Smith wrote:
>On Sun, 2007-01-28 at 13:27 -0800, Bill Harding wrote:
>> In regards to Paul's earlier questions about the version and
>> distribution of my make, it is a Cygwin version of make running on
>> Windows XP. Specifically, if I access my make
On Sun, Jan 28, 2007 at 10:22:52PM +0200, Eli Zaretskii wrote:
>> From: Paul Smith
>> Date: Sun, 28 Jan 2007 09:42:25 -0500
>>
>>
>> * the code that generates that output is conditionally compiled
>> only if MAKE_JOBSERVERS is set, and that macro is set only if
>> the config
On Fri, Jul 28, 2006 at 09:56:20AM -0400, Paul D. Smith wrote:
>%% Christopher Faylor writes:
>cf> If you want to use a Makefile which works in a Cygwin environment,
>cf> however, then obviously you need to build it with a Cygwin gcc.
>
>You'll have to forgive my virtu
On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote:
>In fact, I'm wondering if there is an advantage to building GNU make
>using the Cygwin environment, vs. using a native MingW (for example)
>build of GNU make? I'm afraid I'm woefully ignorant about the details.
There is no advantage
21 matches
Mail list logo
