[PATCHv2] Compile fix for MSVC

[PATCHv2] Compile fix for MSVC

[Vincent van Ravesteijn]

This is a re-roll of the patch series sent to the list 
on 21-10-2011.

This time the lines are not wrapped and the commit messages
are updated with changes from me and Junio.

[PATCH 1/3] Compile fix for MSVC: Do not include sys/resources.h
[PATCH 2/3] Compile fix for MSVC: Include <io.h>
[PATCH 3/3] MSVC: Remove unneeded header stubs

[PATCH 1/3] Compile fix for MSVC: Do not include sys/resources.h

[Vincent van Ravesteijn]

Do not include header files when compiling with MSVC that do not
exist and which are also not included when compiling with MINGW.
A direct consequence is that git can be compiled again with MSVC
because the missing "sys/resources.h" is no longer included.

Instead of current

	#ifndef mingw32 is the only one that is strange
        ... everything for systems that is not strange ...
        #else
        ... include mingw specific tweaks ...
        #endif
        #ifdef msvc is also strange
        ... include msvc specific tweaks ...
        #endif

it turns things around and says what it wants to achieve in a more direct
way, i.e.

	#if mingw32
        #include "compat/mingw.h"
	#elif msvc
        #include "compat/msvc.h"
	#else
        ... all the others ...
	#endif

which makes it look simpler.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
Helped-by: Junio C Hamano <gitster@pobox.com>
---
 git-compat-util.h |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/git-compat-util.h b/git-compat-util.h
index 5ef8ff7..53186da 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -116,7 +116,12 @@
 #else
 #include <poll.h>
 #endif
-#ifndef __MINGW32__
+#if defined(__MINGW32__)
+/* pull in Windows compatibility stuff */
+#include "compat/mingw.h"
+#elif defined(_MSC_VER)
+#include "compat/msvc.h"
+#else
 #include <sys/wait.h>
 #include <sys/resource.h>
 #include <sys/socket.h>
@@ -145,12 +150,6 @@
 #include <grp.h>
 #define _ALL_SOURCE 1
 #endif
-#else 	/* __MINGW32__ */
-/* pull in Windows compatibility stuff */
-#include "compat/mingw.h"
-#endif	/* __MINGW32__ */
-#ifdef _MSC_VER
-#include "compat/msvc.h"
 #endif
 
 #ifndef NO_LIBGEN_H
-- 
1.7.4.1

[PATCH 2/3] Compile fix for MSVC: Include <io.h>

[Vincent van Ravesteijn]

This include is needed for _commit(..) which is used in mingw.h.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
 compat/msvc.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/compat/msvc.h b/compat/msvc.h
index a33b01c..aa4b563 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -4,6 +4,7 @@
 #include <direct.h>
 #include <process.h>
 #include <malloc.h>
+#include <io.h>
 
 /* porting function */
 #define inline __inline
-- 
1.7.4.1

[PATCH 3/3] MSVC: Remove unneeded header stubs

[Vincent van Ravesteijn]

These headers are no longer needed since they are no longer
unnecessarily included in git-compat-util.h.

Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
 compat/vcbuild/include/arpa/inet.h   |    1 -
 compat/vcbuild/include/grp.h         |    1 -
 compat/vcbuild/include/inttypes.h    |    1 -
 compat/vcbuild/include/netdb.h       |    1 -
 compat/vcbuild/include/netinet/in.h  |    1 -
 compat/vcbuild/include/netinet/tcp.h |    1 -
 compat/vcbuild/include/pwd.h         |    1 -
 compat/vcbuild/include/sys/ioctl.h   |    1 -
 compat/vcbuild/include/sys/select.h  |    1 -
 compat/vcbuild/include/sys/socket.h  |    1 -
 compat/vcbuild/include/sys/wait.h    |    1 -
 compat/vcbuild/include/termios.h     |    1 -
 12 files changed, 0 insertions(+), 12 deletions(-)
 delete mode 100644 compat/vcbuild/include/arpa/inet.h
 delete mode 100644 compat/vcbuild/include/grp.h
 delete mode 100644 compat/vcbuild/include/inttypes.h
 delete mode 100644 compat/vcbuild/include/netdb.h
 delete mode 100644 compat/vcbuild/include/netinet/in.h
 delete mode 100644 compat/vcbuild/include/netinet/tcp.h
 delete mode 100644 compat/vcbuild/include/pwd.h
 delete mode 100644 compat/vcbuild/include/sys/ioctl.h
 delete mode 100644 compat/vcbuild/include/sys/select.h
 delete mode 100644 compat/vcbuild/include/sys/socket.h
 delete mode 100644 compat/vcbuild/include/sys/wait.h
 delete mode 100644 compat/vcbuild/include/termios.h

diff --git a/compat/vcbuild/include/arpa/inet.h b/compat/vcbuild/include/arpa/inet.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/arpa/inet.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/grp.h b/compat/vcbuild/include/grp.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/grp.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/inttypes.h b/compat/vcbuild/include/inttypes.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/inttypes.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netdb.h b/compat/vcbuild/include/netdb.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netdb.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/in.h b/compat/vcbuild/include/netinet/in.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netinet/in.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/tcp.h b/compat/vcbuild/include/netinet/tcp.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/netinet/tcp.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/pwd.h b/compat/vcbuild/include/pwd.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/pwd.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/ioctl.h b/compat/vcbuild/include/sys/ioctl.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/ioctl.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/select.h b/compat/vcbuild/include/sys/select.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/select.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/socket.h b/compat/vcbuild/include/sys/socket.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/socket.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/wait.h b/compat/vcbuild/include/sys/wait.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/wait.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/termios.h b/compat/vcbuild/include/termios.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/termios.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
-- 
1.7.4.1

Re: [PATCHv2] Compile fix for MSVC

[Junio C Hamano]

Thanks. The patch looks good from a POSIX person's point of view, and I do
not immediately see how this would break other variants of Windows build
at least from the code inspection.

So I'll queue this, but I'll leave it to you and msysgit folks to decide
if this topic should be merged to 1.7.8-rc1, as I do not have equipment,
expertise, nor time to judge it myself (other than the code inspection we
have already done here).

Please give me an Ack or two by the end of this week. Thanks.

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Johannes Schindelin]

Hi,

On Mon, 31 Oct 2011, Junio C Hamano wrote:

> Thanks. The patch looks good from a POSIX person's point of view, and I 
> do not immediately see how this would break other variants of Windows 
> build at least from the code inspection.

As my virtual machine still ran the test suite after my latest rebasing 
merge when I left work, I could not test the MSVC stuff just yet. I wanted 
to do that tomorrow and either merge or come back with suggestions.

Ciao,
Johannes

Re: [PATCHv2] Compile fix for MSVC

[Erik Faye-Lund]

On Mon, Oct 31, 2011 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks. The patch looks good from a POSIX person's point of view, and I do
> not immediately see how this would break other variants of Windows build
> at least from the code inspection.
>
> So I'll queue this, but I'll leave it to you and msysgit folks to decide
> if this topic should be merged to 1.7.8-rc1, as I do not have equipment,
> expertise, nor time to judge it myself (other than the code inspection we
> have already done here).
>
> Please give me an Ack or two by the end of this week. Thanks.

The result of applying this on top of the current master (1.7.8-rc0)
compiles and seem to runs fine for me, both with the MinGW supplied by
msysGit, and MSVC (as outlined by compat/vcbuild/README). Without the
patches, it fails to build with MSVC. In addition, the changes looks
good to me. So:

Acked-by: Erik Faye-Lund <kusmabite@gmail.com>

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> As my virtual machine still ran the test suite after my latest rebasing 
> merge when I left work, I could not test the MSVC stuff just yet. I wanted 
> to do that tomorrow and either merge or come back with suggestions.

Thanks.

Re: [PATCHv2] Compile fix for MSVC

[Junio C Hamano]

Erik Faye-Lund <kusmabite@gmail.com> writes:

> The result of applying this on top of the current master (1.7.8-rc0)
> compiles and seem to runs fine for me, both with the MinGW supplied by
> msysGit, and MSVC (as outlined by compat/vcbuild/README). Without the
> patches, it fails to build with MSVC. In addition, the changes looks
> good to me. So:
>
> Acked-by: Erik Faye-Lund <kusmabite@gmail.com>

Thanks.

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Erik Faye-Lund]

On Tue, Nov 1, 2011 at 1:09 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 31 Oct 2011, Junio C Hamano wrote:
>
>> Thanks. The patch looks good from a POSIX person's point of view, and I
>> do not immediately see how this would break other variants of Windows
>> build at least from the code inspection.
>
> As my virtual machine still ran the test suite after my latest rebasing
> merge when I left work, I could not test the MSVC stuff just yet. I wanted
> to do that tomorrow and either merge or come back with suggestions.

I've applied the patches to 'devel', verified that the result builds,
and pushed it out.

However, it still doesn't compile with MSVC on top of our 'devel':
make: *** No rule to make target `compat/win32/sys/poll.h', needed by `daemon.o'

The fix for this problem is the following:

---8<---
diff --git a/Makefile b/Makefile
index 2837e79..70edb11 100644
--- a/Makefile
+++ b/Makefile
@@ -518,7 +518,7 @@ LIB_H += compat/mingw.h
 LIB_H += compat/obstack.h
 LIB_H += compat/win32/pthread.h
 LIB_H += compat/win32/syslog.h
-LIB_H += compat/win32/sys/poll.h
+LIB_H += compat/win32/poll.h
 LIB_H += compat/win32/dirent.h
 LIB_H += connected.h
 LIB_H += csum-file.h
---8<---

This is a slip-up in my patch 0f77dea, but I don't quite understand
why this didn't cause any troubles until now... I guess the MSVC parts
of Makefile are somehow more dependent on LIB_H or something...

Junio, is it too late to squash in a fix-up? If it is, I can send a
fixup-patch instead...

Anyway, with that fix in place, it still breaks here:
compat/win32\poll.h(26) : warning C4005: 'POLLIN' : macro redefinition
        C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1495) :
 see previous definition of 'POLLIN'
compat/win32\poll.h(27) : warning C4005: 'POLLPRI' : macro redefinition
        C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1496) :
 see previous definition of 'POLLPRI'
[...]
compat/win32\poll.h(35) : warning C4005: 'POLLWRBAND' : macro redefinition
        C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1500) :
 see previous definition of 'POLLWRBAND'
compat/win32\poll.h(38) : error C2011: 'pollfd' : 'struct' type redefinition
        C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winsock2.h(1506) :
 see declaration of 'pollfd'

Again, this seems to be related to the poll-emulation... I see that
these things are guarded by an "#if(_WIN32_WINNT >= 0x0600)" in
<winsock2.h>, which means it's supported for Windows Vista and
above... We still support Windows XP, so it seems someone has set this
too high :)

And this seems to indeed be the case, as compat/win32/poll.c takes
care to set it to 0x0502 before including. Something like this fixes
that problem for me:
---8<---
diff --git a/compat/mingw.h b/compat/mingw.h
index cdaa7ba..0b8e1aa 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -1,3 +1,4 @@
+#define _WIN32_WINNT 0x0501
 #include <winsock2.h>
 #include <ws2tcpip.h>

diff --git a/git-compat-util.h b/git-compat-util.h
index 0135dcc..e66c21e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,6 +85,7 @@
 #define _SGI_SOURCE 1

 #ifdef WIN32 /* Both MinGW and MSVC */
+#define _WIN32_WINNT 0x0501
 #define WIN32_LEAN_AND_MEAN  /* stops windows.h including winsock.h */
 #include <winsock2.h>
 #include <windows.h>
---8<---

I'd prefer to set this from the Makefile, but this generates a warning
in compat/win32/poll.c about redefining a macro (poll.c wants it to be
0x502, which is Windows XP with SP2, rather than 0x501 which is normal
Windows XP):
---8<---
diff --git a/Makefile b/Makefile
index 2837e79..a4aa785 100644
--- a/Makefile
+++ b/Makefile
@@ -1131,7 +1131,10 @@ ifeq ($(uname_S),Windows)
 	CC = compat/vcbuild/scripts/clink.pl
 	AR = compat/vcbuild/scripts/lib.pl
 	CFLAGS =
-	BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild
-Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H
-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
+	BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild \
+	        -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H \
+		-D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE \
+		-D_WIN32_WINNT=0x501
 	COMPAT_OBJS = compat/msvc.o compat/winansi.o \
 		compat/win32/pthread.o compat/win32/syslog.o \
 		compat/win32/poll.o compat/win32/dirent.o
---8<---

(this will probably both be line-wrapped and white-space-broken, but
you get the point)

...But now I get a complaint about LF_FACESIZE and TMPF_TRUETYPE:
    CC compat/winansi.o
winansi.c
compat/winansi.c(39) : error C2065: 'LF_FACESIZE' : undeclared identifier
compat/winansi.c(39) : error C2057: expected constant expression
compat/winansi.c(56) : warning C4113: 'FARPROC' differs in parameter lists from
'PGETCURRENTCONSOLEFONTEX'
compat/winansi.c(74) : error C2065: 'TMPF_TRUETYPE' : undeclared identifier
make: *** [compat/winansi.o] Error 1

Luckily, Karsten Blees already sent a patch for this:
http://osdir.com/ml/msysgit/2011-10/msg00031.html

...And with that applied, that problem goes away.

Unfortunately, it's not the last error I get:
    LINK git-daemon.exe
daemon.o : error LNK2001: unresolved external symbol _inet_pton
daemon.o : error LNK2001: unresolved external symbol _inet_ntop
git-daemon.exe : fatal error LNK1120: 2 unresolved externals
make: *** [git-daemon.exe] Error 1

The following patch makes that go away:
---8<---
diff --git a/Makefile b/Makefile
index 2837e79..c87c7c5 100644
--- a/Makefile
+++ b/Makefile
@@ -1124,6 +1124,8 @@ ifeq ($(uname_S),Windows)
        NO_CURL = YesPlease
        NO_PYTHON = YesPlease
        BLK_SHA1 = YesPlease
+       NO_INET_PTON = YesPlease
+       NO_INET_NTOP = YesPlease
        NO_POSIX_GOODIES = UnfortunatelyYes
        NATIVE_CRLF = YesPlease
        NO_D_INO_IN_DIRENT = YesPlease
---8<---
(again, probably white-space broken, but you get the point)

And THEN it compiles fine from 'devel'.

So there's some more work left to be done. Unfortunately, I don't have
time to polish these changes for at least a week, so unless someone
volunteers it'll take some time...

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Junio C Hamano]

Erik Faye-Lund <kusmabite@gmail.com> writes:

> This is a slip-up in my patch 0f77dea, but I don't quite understand
> why this didn't cause any troubles until now... I guess the MSVC parts
> of Makefile are somehow more dependent on LIB_H or something...
>
> Junio, is it too late to squash in a fix-up? If it is, I can send a
> fixup-patch instead...

I can queue this for v1.7.8-rc1 if you want, as it is a fix whether or not
we define MSVC or not while building.

-- >8 --
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Tue, 1 Nov 2011 12:56:21 +0100
Subject: [PATCH] mingw: poll.h is no longer in sys/

Earlier we moved this header file in the code but forgot to
update the Makefile that refers to it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 4c09b35..ee34eab 100644
--- a/Makefile
+++ b/Makefile
@@ -515,7 +515,7 @@ LIB_H += compat/mingw.h
 LIB_H += compat/obstack.h
 LIB_H += compat/win32/pthread.h
 LIB_H += compat/win32/syslog.h
-LIB_H += compat/win32/sys/poll.h
+LIB_H += compat/win32/poll.h
 LIB_H += compat/win32/dirent.h
 LIB_H += connected.h
 LIB_H += csum-file.h
-- 
1.7.8.rc0.88.g45c5be

> Anyway, with that fix in place, it still breaks here:
> ...
> Again, this seems to be related to the poll-emulation... I see that
> these things are guarded by an "#if(_WIN32_WINNT >= 0x0600)" in
> <winsock2.h>, which means it's supported for Windows Vista and
> above... We still support Windows XP, so it seems someone has set this
> too high :)
> ...
> And THEN it compiles fine from 'devel'.
>
> So there's some more work left to be done. Unfortunately, I don't have
> time to polish these changes for at least a week, so unless someone
> volunteers it'll take some time...

It seems, from your description, that msvc update series has some way to
go and it probably is better to be cooked by Windows-savvy folks for
another cycle. Which would mean that your upload-archive series is still
good to go as long as it works for non-MSVC/mingw people, right?

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Johannes Schindelin]

Hi kusma,

On Tue, 1 Nov 2011, Erik Faye-Lund wrote:

> On Tue, Nov 1, 2011 at 1:09 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 31 Oct 2011, Junio C Hamano wrote:
> >
> >> Thanks. The patch looks good from a POSIX person's point of view, and 
> >> I do not immediately see how this would break other variants of 
> >> Windows build at least from the code inspection.
> >
> > As my virtual machine still ran the test suite after my latest 
> > rebasing merge when I left work, I could not test the MSVC stuff just 
> > yet. I wanted to do that tomorrow and either merge or come back with 
> > suggestions.
> 
> I've applied the patches to 'devel', verified that the result builds, 
> and pushed it out.

I've applied your patches and made up commit messages. So far, I only 
tested with MSVCE 9.0 (AKA Express 2008) before running out of time. 
Please have a look at the commits (since I could build a git.exe with the 
correct version, I felt comfortable enough to push out to 'devel').

Maybe if someone donates Jenkins resources, we could make an automatic 
branch in the future that has git.sln in it (similar to the 'html' branch 
in git.git).

Ciao,
Dscho

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Erik Faye-Lund]

On Tue, Nov 1, 2011 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> This is a slip-up in my patch 0f77dea, but I don't quite understand
>> why this didn't cause any troubles until now... I guess the MSVC parts
>> of Makefile are somehow more dependent on LIB_H or something...
>>
>> Junio, is it too late to squash in a fix-up? If it is, I can send a
>> fixup-patch instead...
>
> I can queue this for v1.7.8-rc1 if you want, as it is a fix whether or not
> we define MSVC or not while building.

Yes, please do. This looks good to me, thanks for picking it up :)

>> So there's some more work left to be done. Unfortunately, I don't have
>> time to polish these changes for at least a week, so unless someone
>> volunteers it'll take some time...
>
> It seems, from your description, that msvc update series has some way to
> go and it probably is better to be cooked by Windows-savvy folks for
> another cycle.

I don't think you need to hold these three patches; with them I was
able to build your 'master'. I believe the problems I bumped into only
exist in msysgit's 'devel' (or in your 'next', which msysgit/devel is
based upon).

> Which would mean that your upload-archive series is still
> good to go as long as it works for non-MSVC/mingw people, right?
>

Yes. Apart from the slip-up with LIB_H, my upload-archive series
should be unrelated to the issues I found here.

Re: Re: [PATCHv2] Compile fix for MSVC

[Erik Faye-Lund]

On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi kusma,
>
> On Tue, 1 Nov 2011, Erik Faye-Lund wrote:
>> I've applied the patches to 'devel', verified that the result builds,
>> and pushed it out.
>
> I've applied your patches and made up commit messages. So far, I only
> tested with MSVCE 9.0 (AKA Express 2008) before running out of time.
> Please have a look at the commits (since I could build a git.exe with the
> correct version, I felt comfortable enough to push out to 'devel').

The commits look good to me. Thanks for following up on it :)

> Maybe if someone donates Jenkins resources, we could make an automatic
> branch in the future that has git.sln in it (similar to the 'html' branch
> in git.git).

CloudBees seems to have some kind of a free Jenkins service. Perhaps
it's sufficient?
http://www.cloudbees.com/dev-pricing.cb

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Junio C Hamano]

Erik Faye-Lund <kusmabite@gmail.com> writes:

>> It seems, from your description, that msvc update series has some way to
>> go and it probably is better to be cooked by Windows-savvy folks for
>> another cycle.
>
> I don't think you need to hold these three patches; with them I was
> able to build your 'master'. I believe the problems I bumped into only
> exist in msysgit's 'devel' (or in your 'next', which msysgit/devel is
> based upon).

Ok, then. Thanks for clarifying.

Re: Re: [PATCHv2] Compile fix for MSVC

[Vincent van Ravesteijn]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

> Maybe if someone donates Jenkins resources, we could make an automatic
> branch in the future that has git.sln in it (similar to the 'html' branch
> in git.git).
>

As long as this means to just run a not so complicated perl script, this
Could even be done in a commit hook.

Just another question. How does the (msys)git community feel about adding
CMake support ? I can probably do that quite easily.

Vincent

[-- Attachment #2: Type: text/html, Size: 481 bytes --]

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Johannes Schindelin]

Hi,

On Tue, 1 Nov 2011, Vincent van Ravesteijn wrote:

> > Maybe if someone donates Jenkins resources, we could make an automatic 
> > branch in the future that has git.sln in it (similar to the 'html' 
> > branch in git.git).
> 
> As long as this means to just run a not so complicated perl script, this 
> Could even be done in a commit hook.

I actually was thinking about something automatic which does not require 
any of the busy msysGit developers to do something manual every once in a 
while.

> Just another question. How does the (msys)git community feel about 
> adding CMake support ? I can probably do that quite easily.

There was somebody who strongly favored CMake over any other solution but 
was not willing to maintain it in the long run (also, I have to admit that 
I have had quite a few problems with CMake, but maybe I am just pampered 
by projects that Just Compile...)

Ciao,
Johannes

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Johannes Schindelin]

Hi kusma,

On Tue, 1 Nov 2011, Erik Faye-Lund wrote:

> On Tue, Nov 1, 2011 at 7:40 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Maybe if someone donates Jenkins resources, we could make an automatic 
> > branch in the future that has git.sln in it (similar to the 'html' 
> > branch in git.git).
> 
> CloudBees seems to have some kind of a free Jenkins service. Perhaps 
> it's sufficient? http://www.cloudbees.com/dev-pricing.cb

Looks quite cool, but keep in mind: they only have Linux build machines. 
We'd need to pimp up our cross-platform compiling capabilities; WINE will 
most likely not be good enough (we'd only have 2000 minutes per month).

Ciao,
Dscho

Re: Re: [PATCHv2] Compile fix for MSVC

[Vincent van Ravesteijn]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

>
>
> > > Maybe if someone donates Jenkins resources, we could make an automatic
> > > branch in the future that has git.sln in it (similar to the 'html'
> > > branch in git.git).
> >
> > As long as this means to just run a not so complicated perl script, this
> > Could even be done in a commit hook.
>
> I actually was thinking about something automatic which does not require
> any of the busy msysGit developers to do something manual every once in a
> while.


I thought that a commit hook, was something automatic (iff the busy
developers
do commit something once in a while). I guess I can even set this up very
easily
(given push rights, otherwise it will involve manual labor again).



> > Just another question. How does the (msys)git community feel about
> > adding CMake support ? I can probably do that quite easily.
>
> There was somebody who strongly favored CMake over any other solution but
> was not willing to maintain it in the long run (also, I have to admit that
> I have had quite a few problems with CMake, but maybe I am just pampered
> by projects that Just Compile...)
>

The current way of generating a MSVC project is rather outdated, so the
worst
thing that can happen is that you have a different build system which is not
maintained. At least the CMake people will continue to improve on their
side.

Vincent

[-- Attachment #2: Type: text/html, Size: 2011 bytes --]

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Pat Thoyts]

On 1 November 2011 22:32, Vincent van Ravesteijn <vfr@lyx.org> wrote:
>
>> Maybe if someone donates Jenkins resources, we could make an automatic
>> branch in the future that has git.sln in it (similar to the 'html' branch
>> in git.git).
>>
>
> As long as this means to just run a not so complicated perl script, this
> Could even be done in a commit hook.
>
> Just another question. How does the (msys)git community feel about adding
> CMake support ? I can probably do that quite easily.
>
> Vincent
>

-1. We have a make. We don't need two of them.

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Vincent van Ravesteijn]

Op 2-11-2011 1:48, Pat Thoyts schreef:
> On 1 November 2011 22:32, Vincent van Ravesteijn<vfr@lyx.org>  wrote:
>>> Maybe if someone donates Jenkins resources, we could make an automatic
>>> branch in the future that has git.sln in it (similar to the 'html' branch
>>> in git.git).
>>>
>> As long as this means to just run a not so complicated perl script, this
>> Could even be done in a commit hook.
>>
>> Just another question. How does the (msys)git community feel about adding
>> CMake support ? I can probably do that quite easily.
>>
>> Vincent
>>
> -1. We have a make. We don't need two of them.

Make won't offer anything if you want to support MSVC. So, if you want 
to support MSVC, there has to be some sort of alternative.

Vincent

Re: [msysGit] Re: [PATCHv2] Compile fix for MSVC

[Sebastian Schuberth]

On 02.11.2011 01:48, Pat Thoyts wrote:

>> As long as this means to just run a not so complicated perl script, this
>> Could even be done in a commit hook.
>>
>> Just another question. How does the (msys)git community feel about adding
>> CMake support ? I can probably do that quite easily.
>
> -1. We have a make. We don't need two of them.

I don't see CMake as an alternative to make as CMake would be used to 
generate the Makefile, which is currently hard-coded and committed.

However, I don't see any benefit in using CMake as long as the Linux 
guys don't use it to create their Makefile, too.

-- 
Sebastian Schuberth