Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones <ram...@ramsay1.demon.co.uk>
Let me try to understand this.
Before v184.108.40.206~7^2~2 (Update cygwin.c for new mingw-64 win32 api
headers, 2012-11-11), compat/cygwin.c did
Afterward, on modern Cygwin it changed to
#ifndef WIN32 /* Not defined by Cygwin */
and then defines some inline functions relying on the win32 api.
git-compat-util.h defines various feature request macros and includes
many system headers, so that simple swap of lines was a huge change.
It's not obvious to me what part was important for making this work
with modern Cygwin win32api. Mark or others, do you remember what
went wrong with the original "git-compat-util.h and then
compat/win32.h" order (e.g., did it break the build? what was the
compiler message?) when upgrading win32api?
Unfortunately this was a breaking change: systems with the *old*
version of win32api would only compile with the old order of header
inclusions. The new ordering produced the following symptom:
In file included from compat/../git-compat-util.h:90,
warning: #warning "fd_set and associated macros have been defined in
This may cause runtime problems with W32 sockets"
In file included from /usr/include/sys/socket.h:16,
/usr/include/cygwin/socket.h:29: error: redefinition of `struct
Alex Riesen (cc-ed) noticed that removing the following lines from
git-compat-util.h alleviated this new symptom:
#ifdef WIN32 /* Both MinGW and MSVC */
# if defined (_MSC_VER)
# define _WIN32_WINNT 0x0502
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
After all, on Cygwin there is no reason to include winsock or the
win32api from git-compat-util.h. Presumably one of <sys/stat.h>,
<sys/errno.h>, and <windows.h> causes the WIN32 macro to be defined on
these systems with old win32api, and chaos ensues.
All in all, it wasn't a bad thing, since it revealed that the WIN32
macro doesn't mean what most of the git codebase assumes it means
(hence patch 1/2, which fixes that).
The reordering made in v220.127.116.11~7^2~2 still seems like voodoo to me,
but at least it works. This patch applies that same order for
everyone. Systems that would previously use the "I have old win32api
and don't need that reordering" codepath don't need to be
special-cased any more, since *their* particular brand of trouble is
avoided by being careful about how to use the WIN32 macro.
- No change on modern setups. To uninformed people like me I feel
like there is still something subtle going on that is not well
understood, but hey, this patch doesn't break it. :)
- Tested to still work on setups that previously needed
- This drops an #ifdef, which means less code that is never tested
to keep up to date.
With or without a few words of explanation in the commit message to
save some time for the next confused person looking this over,
Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html