On 1/18/2012 11:00 AM, Paul Smith wrote:
The windows jobserver patch was promoted to CVS on Nov 15. It should be
all set (as far as I know).
Cool, any ideas when this would make it into a release?
-Bill
___
Make-w32 mailing list
Make-w32@gnu.org
h
On 9/20/2011 5:42 PM, Paul Smith wrote:
On Tue, 2011-09-20 at 17:06 -0400, Chris Sutcliffe wrote:
On 18 July 2011 15:30, Troy Runkel wrote:
Attached is an update for the port of jobserver to Windows that I
originally submitted in October of 2010.
Was this patch ever included? I'd love to see
Paul Smith wrote:
If it's a generic problem with make, not related specifically to
Windows, you should either file a bug in Savannah (preferred) or email
to the bug-m...@gnu.org mailing list... even for CVS-based versions.
Seems to be a generic problem. I have created a bug report here:
htt
Bill Hoffman wrote:
I did a CVS checkout of gmake on this date:
checkout date: 2009-12-30 16:00
$ cat CVS/Root
:pserver:anonym...@cvs.savannah.gnu.org:/sources/make
$ cat CVS/Repository
make
I have the cygwin built make renamed to make.orig:
$ make.orig --version
GNU Make 3.81
$ make
I did a CVS checkout of gmake on this date:
checkout date: 2009-12-30 16:00
$ cat CVS/Root
:pserver:anonym...@cvs.savannah.gnu.org:/sources/make
$ cat CVS/Repository
make
I have the cygwin built make renamed to make.orig:
$ make.orig --version
GNU Make 3.81
$ make --version
GNU Make 3.81.90
I
Rob Walker wrote:
It's been a while since this patch was made available:
http://lists.gnu.org/archive/html/make-w32/2006-09/msg00037.html
It seems to be working for the world at large, and it's working very
well in my organization.
Have there been any improvements to it? Any known issues wi
Paul Smith wrote:
On Thu, 2008-07-03 at 11:26 -0400, Bill Hoffman wrote:
I think this is a known limitation, that the job server is not
implemented on certain platforms. I googled a bit, and it seemed
like it has something to do with having or not having named pipes.
Perhaps some of the
Christopher Faylor wrote:
If there is a mingw jobserver issue, it sounds like a bug. Has it been
filed?
I think this is a known limitation, that the job server is not
implemented on certain platforms. I googled a bit, and it seemed like
it has something to do with having or not having nam
Christopher Faylor wrote:
On Mon, Jun 30, 2008 at 06:27:29PM -0700, Kelly O'Hair wrote:
Thanks. And I understand the "no guarantee" issue, we ran into
a problem with find.exe too a while back.
I also understand their point of view on these paths being problematic,
but unfortunately the OpenJDK
Eli Zaretskii wrote:
Date: Mon, 30 Jun 2008 18:08:00 -0700
From: "Kelly O'Hair" <[EMAIL PROTECTED]>
I assume cygwin will not be fixing this, in 3.82 or ever, is that
the conclusion I am seeing?
DOS file name support for Cygwin is already in CVS and will be in the
next release of GNU Make.
A
Fabrice GIRARDOT wrote:
Bill Hoffman wrote :
What shell/make are you using for windows and -j ?
Shell is cmd.exe and I'm runing an own-compiled Make
based on v3.81 that includes a windows-specific bug fix.
The bug fix deals with the -n option.
Thanks, Eli helped me figure it out.
Fabrice GIRARDOT wrote:
Marc Harbonne wrote :
Does the option make –j can improve the compilation time ?
Yes. On a Core2 Duo @ 2.13 GHz running Win2k with "only"
1 GB RAM, "make -j8" is about 40% than "make".
The "8" value was determined by differents tries.
You'll have to find with value b
Eli Zaretskii wrote:
Date: Fri, 08 Dec 2006 21:46:18 -0500
From: Bill Hoffman <[EMAIL PROTECTED]>
So, the windows native stat is about 3 X faster.
This is not really a valid conclusion: `stat' does much more than just
get the file's attributes via a single Win32 API call
Earnie Boyd wrote:
Quoting Bill Hoffman <[EMAIL PROTECTED]>:
real0m39.404s
user0m0.031s
sys 0m0.062s
Hmm... Are these from Cygwin's shell? Is it possible that these
timings do not reflect actualness due to your native program would not
use the Cygwin runtim
Christopher Faylor wrote:
e you'd have headaches with the emulated POSIX paths.
Right. That plus the whole point of Cygwin (MSYS) is to use the
linux-like interface.
This maybe true, but the performance increase for make could be
significant. I just created
a small test program an
Bill Hoffman wrote:
Christopher Faylor wrote:
Thanks.
Why should the msvcrt _stat be slow? I wouldn't assume that to be
the case.
We did not assume it would be slow either. However, at some point we
made the change in
cmake because we found that much of the run time on wi
Christopher Faylor wrote:
Thanks.
Why should the msvcrt _stat be slow? I wouldn't assume that to be the case.
We did not assume it would be slow either. However, at some point we
made the change in
cmake because we found that much of the run time on windows was spent in
stat, and
Earnie Boyd wrote:
Quoting Bill Hoffman <[EMAIL PROTECTED]>:
So, if I run gmake (the patched cygwin version) and nmake
(Microsoft's make) on roughly
the same tree. (CMake can generate files for either.) nmake is
able to check the depend information
about twice as fast as gma
So, if I run gmake (the patched cygwin version) and nmake (Microsoft's
make) on roughly
the same tree. (CMake can generate files for either.) nmake is able
to check the depend information
about twice as fast as gmake can. I suspect that the problem is in the
use of stat. Although windows/
With the patched cygwin build of make I am having some trouble with
escaped () in depend
lines in makefiles.
all: C:/Program\ Files\ \(x86\)/CMake\
2.4/share/cmake-2.4/Modules/TestBigEndian.c
echo hello or something
I get this:
make: *** No rule to make target `C:/Program Files \(x86\)/CM
Eli Zaretskii wrote:
Date: Fri, 17 Nov 2006 15:23:10 +0100
From: Benoit Sigoure <[EMAIL PROTECTED]>
Did you patch the stock Cygwin sources of Make 3.81 or the ones that
have the HAVE_DOS_PATHS patch applied? The patch I sent will only
work with the latter, not with the former.
OK I
Benoit Sigoure wrote:
I have the same problem with stock cygwin GNU make 3.81:
I can verify that, I just downloaded the cygwin binary for make 3.81 from
http://mirror.calvin.edu/cygwin/release/make/ and it has the same issue.
So, I think it is safe to say the patch did not cause the problem.
-
Eli Zaretskii wrote:
Date: Thu, 16 Nov 2006 13:53:44 -0500
From: Bill Hoffman <[EMAIL PROTECTED]>
Cc: make-w32@gnu.org
I see the same thing, and have seen this with mingw make as well.
I don't see this with the MinGW compiled Make 3.81. Can you please
show an
Benoit Sigoure wrote:
Hello people,
I am under cygwin and compiled my own GNU make 3.81 from source with this patch
applied:
http://thread.gmane.org/gmane.comp.gnu.make.windows/2058/focus=2147
$ uname -a
CYGWIN_NT-5.1 bf-winxp 1.5.21(0.156/4/2) 2006-07-30 14:21 i686 Cygwin
$ make --version
GNU
Jon Grant wrote:
Hi Paul,
Could these MSVC.NET 2005 project files be imported (contained within
zip) please. They are from Microsoft's newer compiler.
Kind regards
Jon
If I created them, would CMakeList.txt files be added to the project?
They could be used to build gmake on windows for any
At 05:10 PM 8/17/2006, Eli Zaretskii wrote:
>I use a shell that is a native Windows program, not a Cygwin
>program. (There could be some quoting conflict between the Cygwin
>and non-Cygwin binaries.)
To reproduce the problem you have to run from a cygwin shell or a msys shell.
-Bill
__
At 04:48 PM 8/17/2006, Christopher Faylor wrote:
>I don't understand why MinGW's make should be using anything like /bin/sh.
>Shouldn't it be using cmd.exe or command.com?
>
>cgf
It seems that if it finds sh.exe in the path it uses it.
Remember the chars_sh and chars_dos thing that is switched a
As requested by Eli, I am posting the problems I am having with mingw-make
from a cygwin command line.
I narrowed down the major problem with mingw make and my makefiles.
Looks like a process launching issue. If the files are double quoted
and passed to a full path command it passes both files a
At 01:21 PM 8/17/2006, Christopher Faylor wrote:
>On Thu, Aug 17, 2006 at 12:38:29PM -0400, Bill Hoffman wrote:
>>At 11:42 AM 8/17/2006, Christopher Faylor wrote:
>>>On Thu, Aug 17, 2006 at 10:23:35AM -0400, Bill Hoffman wrote
>
>I'm not a make maintainer and don
At 11:42 AM 8/17/2006, Christopher Faylor wrote:
>On Thu, Aug 17, 2006 at 10:23:35AM -0400, Bill Hoffman wrote:
>
>
>>if (p[1] != '\\' && p[1] != '\''
>>&& !isspace ((unsigned char)p
At 11:40 PM 8/16/2006, Christopher Faylor wrote:
>I don't understand why isn't this just using the UNIX-ish settings for
>Cygwin. The settings should, at the very least, be the same as the
>UNIX-sh case.
Because there was a bug where sh_chars_sh was being directly referenced if
HAVE_DOS_PATHS wa
I tried compiling 3.81 on cygwin with HAVE_DOS_PATHS,
and found the same crash described in this thread:
http://www.mail-archive.com/make-w32@gnu.org/msg00861.html
I found the problem and fixed the crash.
Here is the patch:
*** make-3.81/job.c Sun Mar 19 22:03:04 2006
--- ../make-3.81/job.c
So, this has come up on this list before. You are aware that
cygwin made a change and stopped applying a local patch that allowed
for posix paths and windows paths in the same makefile. After
much discussion on the cygwin list, it was recommend to move the discussion
here. The cygwin folks say
33 matches
Mail list logo
