On 01/22/2013 01:31 PM, Ramsay Jones wrote:
include order. ;-) As I have mentioned here before, the claim that
WIN32 is not defined on cygwin is simply nonsense - it depends on
if/when certain header files are included. For example, *as soon as*
you include windows.h (and, I suspect, many
Mark Levedahl mleved...@gmail.com writes:
Cygwin and Windows should be treated as completely separate platforms:
if __CYGWIN__ is defined, do one thing, if not, go ahead and check
WIN32, but the WIN32 macro should never be tested once we know the
platform is CYGWIN - these really are
On 01/25/2013 05:11 PM, Junio C Hamano wrote:
Mark Levedahl mleved...@gmail.com writes:
Cygwin and Windows should be treated as completely separate platforms:
if __CYGWIN__ is defined, do one thing, if not, go ahead and check
WIN32, but the WIN32 macro should never be tested once we know the
Jonathan Nieder wrote:
Ramsay Jones wrote:
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,12 +85,6 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
-#include
Torsten Bögershausen wrote:
On 20.01.13 12:06, Jonathan Nieder wrote:
Torsten Bögershausen wrote:
I wonder, if if we can go one step further:
Replace
#ifdef WIN32 /* Both MinGW and MSVC */
[...]
with
#if defined(_MSC_VER)
I thought Git for Windows was built using mingw, which doesn't
Ramsay Jones wrote:
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,12 +85,6 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
-#include winsock2.h
-#include
On 20.01.13 11:10, Jonathan Nieder wrote:
Ramsay Jones wrote:
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,12 +85,6 @@
#define _NETBSD_SOURCE 1
#define _SGI_SOURCE 1
-#ifdef WIN32 /* Both MinGW and MSVC */
-#define WIN32_LEAN_AND_MEAN /* stops windows.h including
Torsten Bögershausen wrote:
I wonder, if if we can go one step further:
Replace
#ifdef WIN32 /* Both MinGW and MSVC */
[...]
with
#if defined(_MSC_VER)
I thought Git for Windows was built using mingw, which doesn't define
_MSC_VER?
Puzzled,
Jonathan
--
To unsubscribe from this list: send
On 20.01.13 12:06, Jonathan Nieder wrote:
Torsten Bögershausen wrote:
I wonder, if if we can go one step further:
Replace
#ifdef WIN32 /* Both MinGW and MSVC */
[...]
with
#if defined(_MSC_VER)
I thought Git for Windows was built using mingw, which doesn't define
_MSC_VER?
Mark Levedahl wrote:
On 01/11/2013 03:17 PM, Alex Riesen wrote:
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen raa.l...@gmail.com wrote:
This short discussion on GitHub (file git-compat-util.h) might be relevant:
This short discussion on GitHub (file git-compat-util.h) might be relevant:
https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
The change suggested there (to remove an inclusion of windows.h in
git-compat-util.h) might simplify the solution a
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen raa.l...@gmail.com wrote:
This short discussion on GitHub (file git-compat-util.h) might be relevant:
https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomment-2407194
The change suggested there (to remove an
-Original Message-
From: Junio C Hamano
Sent: Monday, January 07, 2013 2:29 AM
Jason Pyeron writes:
[administrivia: please never cull CC list when you respond to a
message on this list without a good reason]
Apologies, I just have 4 copies of every message and was trying to save
Hi,
Torsten Bögershausen wrote:
Stephen Linda Smith wrote:
git co 9fca6c make all
... The make errored out as before
[...]
git co 9fca6c^ make all
... and this compiles to completion
CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22
i686 Cygwin
[...]
You can either
On 06.01.13 10:32, Jonathan Nieder wrote:
Hi,
Torsten Bögershausen wrote:
Stephen Linda Smith wrote:
git co 9fca6c make all
... The make errored out as before
[...]
git co 9fca6c^ make all
... and this compiles to completion
CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3)
Torsten Bögershausen wrote:
The short version:
Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
[...]
I don't know if we want to improve the Makefile to enable
CYGWIN_V15_WIN32API = YesPlease
for cygwin versions 1.7.1 .. 1.7.16 (which are outdated)
Confusing.
On 01/06/2013 04:57 AM, Jonathan Nieder wrote:
Torsten Bögershausen wrote:
The short version:
Cygwin versions 1.7.1 up to 1.7.16 use the same header files as cygwin 1.5
[...]
I don't know if we want to improve the Makefile to enable
CYGWIN_V15_WIN32API = YesPlease
for cygwin versions 1.7.1
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by having dll version 1.7.x, while the older frozen
releases (dll versions 1.6.x from redhat,
On Sunday, January 06, 2013 04:09:17 AM Jonathan Nieder wrote:
Mark Levedahl wrote:
However, the
newer
win32api is provided only for the current cygwin release series, which
Jonathan Nieder jrnie...@gmail.com writes:
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by having dll version 1.7.x, while the older frozen
On 06.01.13 20:54, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by having
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Mark Levedahl wrote:
However, the newer
win32api is provided only for the current cygwin release series, which can
be reliably identified by
Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Mark Levedahl wrote:
However,
the newer win32api is provided only
On 01/06/2013 03:51 PM, Torsten Bögershausen wrote:
Hm, I haven't understood the connection between the dll (cygwin1.dll
?) which is used in runtime, and the header files which are used when
compiling. Are they updated at the same time when updating from 1.7.16
to 1.7.17 ? Until I updated my
Thanks; so perhaps you can give me an OK to forge your S-o-b to the
following?
-- 8 --
From: Mark Levedahl mleved...@gmail.com
Date: Sun, 6 Jan 2013 11:56:33 -0800
Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
There is no documented, reliable, and future-proof method to
determine
-Original Message-
From: Junio C Hamano
Sent: Sunday, January 06, 2013 16:36
Thanks; so perhaps you can give me an OK to forge your S-o-b
to the following?
I am personally fine with it, because cygwin is used by developers not
production systems and I expect my developers to
On 01/06/2013 04:35 PM, Junio C Hamano wrote:
Thanks; so perhaps you can give me an OK to forge your S-o-b to the
following?
-- 8 --
From: Mark Levedahl mleved...@gmail.com
Date: Sun, 6 Jan 2013 11:56:33 -0800
Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
There is no
-Original Message-
From: Mark Levedahl
Sent: Sunday, January 06, 2013 17:17
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Mark Levedahl wrote:
However,
the newer
Jason Pyeron jpye...@pdinc.us writes:
[administrivia: please never cull CC list when you respond to a
message on this list without a good reason]
circumvent the Cygwin API (and by extension, Cygwin project goals).
So, perhaps a better path forward is to disable / remove the
above code by
Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message states that
the macro was being renamed for clarity. The patch also changes a define.
This change causes the code to not compile on cygwin 1.7.14.
I narrowed the problem to this patch by bisecting commits between v1.8.0 and
1.8.1
Here
Stephen Linda Smith
Sent: Saturday, January 05, 2013 21:05
Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message
states that the macro was being renamed for clarity. The
patch also changes a define.
Was it the commit before 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles
or
-Original Message-
From: Jason Pyeron
Sent: Saturday, January 05, 2013 22:38
Stephen Linda Smith
Sent: Saturday, January 05, 2013 21:05
Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message
states that
the macro was being renamed for clarity. The patch also
-Original Message-
From: Stephen Linda Smith
Sent: Sunday, January 06, 2013 1:21
Was it the commit before
9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it
9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
am doing a
cygwin update presently to look
On 06.01.13 07:29, Jason Pyeron wrote:
-Original Message-
From: Stephen Linda Smith
Sent: Sunday, January 06, 2013 1:21
Was it the commit before
9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it
9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
am doing a
34 matches
Mail list logo
