On 01/25/2013 05:11 PM, Junio C Hamano wrote:
> Mark Levedahl 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
Mark Levedahl 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 different platforms (if
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 (and, I suspect, many other win32
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
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
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
> _MS
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:
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 i
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
> -#include
> -#en
Mark Levedahl wrote:
> On 01/11/2013 03:17 PM, Alex Riesen wrote:
>> On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen wrote:
>>> This short discussion on GitHub (file git-compat-util.h) might be relevant:
>>>
>>> https://github.com/msysgit/git/commit/435bdf8c7ffa493f8f6f2e8f329f8cc22db16ce6#commitcomm
On 01/11/2013 03:17 PM, Alex Riesen wrote:
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen 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
On Fri, Jan 11, 2013 at 9:08 PM, Alex Riesen 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 inclusion of windo
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 litt
On 01/07/2013 02:29 AM, Junio C Hamano wrote:
I do not have much stake in this personally, but IIRC, the (l)stat
workaround was back then found to make Cygwin version from "unusably
slow" to "slow but torelable", as our POSIX-y codebase assumes that
lstat is fairly efficient, which Cygwin cannot
> -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
"Jason Pyeron" 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 default.
> -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 writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>
> However,
> >>> the newer w
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder 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.
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
Date: Sun, 6 Jan 2013 11:56:33 -0800
Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API
There is no documented, reliable, and fut
> -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
Thanks; so perhaps you can give me an OK to forge your S-o-b to the
following?
-- >8 --
From: Mark Levedahl
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 the installed w32a
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 cy
git@vger.kernel.org; Eric Blake
> 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 writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>
On 01/06/2013 02:54 PM, Junio C Hamano wrote:
Jonathan Nieder 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.
On 06.01.13 20:54, Junio C Hamano wrote:
> Jonathan Nieder 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 v
Jonathan Nieder 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
>> releases (
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
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, 1
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 .
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 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 WIN
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 Cygw
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 compile
> -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 pres
> Was it the commit before
> 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was
> it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I
> am doing a cygwin update presently to look at it.
Since the email earlier today, I had blown away the directory. I just now
did the foll
> -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
> 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 compil
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 i
38 matches
Mail list logo
