{"thread":{"id":"21107","subject":"MSVC build broken (on cygwin)","startedAt":"2009-10-01T17:11:30Z","lastAt":"2009-10-03T20:29:31Z","messageCount":7,"participants":["Ramsay Jones","Marius Storm-Olsen","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"124092","messageId":"4AC4E2C2.6030509@ramsay1.demon.co.uk","threadId":"21107","inReplyTo":null,"subject":"MSVC build broken (on cygwin)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2009-10-01T17:11:30Z","receivedAt":"2009-10-01T17:11:30Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Hi Marius,\n\nI know that I'm somewhat late to comment on your recent MSVC\nbuild patches, but I was busy at the time; better late than\nnever... maybe ;-)\n\nWhile the patches were traversing the list, I was feeling\nsomewhat nervous about the effect of the patches on the\ncygwin build; in fact I remember thinking that they had\n*probably* broken the build. But I was busy...\n\nWell I finally found time, yesterday, to take a closer look.\nI spent 10-15 minutes squinting at the code in order to\nconvince myself that you had in fact *not* broken the cygwin\nbuild. :)\n\n(which I already suspected, since they were committed some time \nago and nobody else had screamed!)\n\n[Note: I was mainly concerned about commit 435bdf8 and, to a\nlesser degree, commit 71064e3]\n\nI'm sure you are probably aware of the following, but for the\nbenefit of others, the following session on cygwin may help to\nexplain my nervousness:\n\n    $ cat -n hello.c\n         1\t#include <stdio.h>\n         2\t\n         3\t#ifdef IW_H\n         4\t# include <windows.h>\n         5\t#endif\n         6\t\n         7\tint main(int argc, char *argv[])\n         8\t{\n         9\t\n        10\t#ifdef __CYGWIN__\n        11\t\tprintf(\"__CYGWIN__\\n\");\n        12\t#endif\n        13\t#ifdef __MINGW32__\n        14\t\tprintf(\"__MINGW32__\\n\");\n        15\t#endif\n        16\t#ifdef _WIN32\n        17\t\tprintf(\"_WIN32\\n\");\n        18\t#endif\n        19\t#ifdef WIN32\n        20\t\tprintf(\"WIN32\\n\");\n        21\t#endif\n        22\t\tprintf(\"Hello world\\n\");\n        23\t\treturn 0;\n        24\t}\n        25\t\n    $ \n\n    $ gcc hello.c\n    $ ./a.exe\n    __CYGWIN__\n    Hello world\n    $ \n\n    $ gcc -DIW_H hello.c\n    $ ./a.exe\n    __CYGWIN__\n    _WIN32\n    WIN32\n    Hello world\n    $ \n\n    $ gcc -mno-cygwin hello.c\n    $ ./a.exe\n    __MINGW32__\n    _WIN32\n    WIN32\n    Hello world\n    $ \n[Note: I don't know if the above is exactly equivalent to an\nMSYS/Mingw-gcc installation, but it does, at least, not link with\nthe cygwin dll]\n\nHowever, while squinting at the code, I noticed what I think is a\nproblem with the MSVC build on cygwin. Viz:\n\n    $ cl hello.c\n    [...compiler output snipped...]\n    $ ./hello.exe\n    _WIN32\n    Hello world\n    $ \n\n    $ cl -DIW_H hello.c\n    [...compiler output snipped...]\n    $ ./hello.exe\n    _WIN32\n    WIN32\n    Hello world\n    $ \n\n    $ cl -DWIN32-D_CONSOLE hello.c\n    [...compiler output snipped...]\n    $ ./hello.exe\n    _WIN32\n    Hello world\n    $ \n\nNote the last compiler command line above. As part of commit 164a5e3,\nthe Makefile (on line 917) sets the BASIC_CFLAGS macro to contain the\nabove string. I had expected the compiler to complain about this\nmalformed -Define (gcc does), but it remains quiet and seems to be\nignoring the parameter entirely. So I tried upping the warning level:\n\n    $ cl -W4 -DWIN32-D_CONSOLE hello.c\n    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86\n    Copyright (C) Microsoft Corporation.  All rights reserved.\n\n    hello.c\n    hello.c(7) : warning C4100: 'argv' : unreferenced formal parameter\n    hello.c(7) : warning C4100: 'argc' : unreferenced formal parameter\n    Microsoft (R) Incremental Linker Version 9.00.30729.01\n    Copyright (C) Microsoft Corporation.  All rights reserved.\n\n    /out:hello.exe \n    hello.obj \n    $ ./hello.exe\n    _WIN32\n    Hello world\n    $ \n\n[Note: I also tried the above using the \"Visual Studio 2008 command\nprompt\" with exactly the same result]\n\nSo, at least on cygwin with the version of msvc I'm using (see above),\nthe build should be broken; as a quick check I made the following\nchange (on top of commit f5c3178):\n\n-- >8 --\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 8d6e29c..72275a3 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -69,6 +69,8 @@\n #define WIN32_LEAN_AND_MEAN  /* stops windows.h including winsock.h */\n #include <winsock2.h>\n #include <windows.h>\n+#else\n+#error \"WIN32 *not* defined in MSVC build\"\n #endif\n \n #include <unistd.h>\n-- >8 --\n\nand then tried to build using msvc, thus:\n\n    $ make MSVC=1\n    GIT_VERSION = 1.6.5.rc1.37.gf5c31.dirty\n        * new build flags or prefix\n        CC fast-import.o\n    fast-import.c\n    c:\\cygwin\\home\\ramsay\\git\\git-compat-util.h(73) : fatal error C1189: #error :  \"WIN32 *not* defined in MSVC build\"\n    [...lots of similar output (940 lines) snipped...]\n    $ \n\nFinally, I removed the above change and applied the patch given below.\nNow, I didn't expect this to work because I don't have all of the\ndependencies installed, and those that I do have installed are not\nwhere the Makefile expects them to be (eg zlib is at C:\\zlib).\nHowever, the build does at least compile all of the C source files, but\nthen all of the link's fail since it can't find zlib.lib.\n\n[Note: I was a little surprised that it got that far, since I didn't\nexpect it to find the zlib header files. However, I have set the\nINCLUDE environment variable which msvc is respecting! yeah, a bit old\nfashioned!  Having also set the LIB environment variable, I was then\na bit surprised that the linker didn't find the library; until I\nnoticed that my library is called libz.lib *not* zlib.lib!]\n\nNote that the patch below includes some line-wrapping which you can\nignore if you like, it just makes the Makefile easier to read.\nThe only change that matters is inserting a space between -DWIN32 and\n-D_CONSOLE.\n\nAnyway, the point is *not* to get the msvc build to work for me; rather\nit is to understand why the build *works* for you. ;-)\n\nATB,\nRamsay Jones\n\n-- >8 --\nFrom: Ramsay Jones <ramsay@ramsay1.demon.co.uk>\nDate: Wed, 30 Sep 2009 20:08:41 +0100\nSubject: [PATCH] Fix the MSVC build on cygwin\n\n\nSigned-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>\n---\n Makefile |   13 ++++++++++---\n 1 files changed, 10 insertions(+), 3 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 12defd4..e6ec8ed 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -914,10 +914,17 @@ ifdef MSVC\n \tCC = compat/vcbuild/scripts/clink.pl\n \tAR = compat/vcbuild/scripts/lib.pl\n \tCFLAGS =\n-\tBASIC_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\n+\tBASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild \\\n+\t\t       -Icompat/vcbuild/include -DWIN32 -D_CONSOLE \\\n+\t\t       -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS \\\n+\t\t       -D_CRT_NONSTDC_NO_DEPRECATE\n \tCOMPAT_OBJS = compat/msvc.o compat/fnmatch/fnmatch.o compat/winansi.o\n-\tCOMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch -Icompat/regex -Icompat/fnmatch -DSTRIP_EXTENSION=\\\".exe\\\"\n-\tBASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib\n+\tCOMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H \\\n+\t\t\t-DHAVE_ALLOCA_H -Icompat -Icompat/fnmatch \\\n+\t\t\t-Icompat/regex -Icompat/fnmatch \\\n+\t\t\t-DSTRIP_EXTENSION=\\\".exe\\\"\n+\tBASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE \\\n+\t\t\t-NODEFAULTLIB:MSVCRT.lib\n \tEXTLIBS = advapi32.lib shell32.lib wininet.lib ws2_32.lib\n \tlib =\n ifndef DEBUG\n-- \n1.6.4\n"},{"id":"124118","messageId":"4AC5B4AE.5070307@gmail.com","threadId":"21107","inReplyTo":"4AC4E2C2.6030509@ramsay1.demon.co.uk","subject":"Re: MSVC build broken (on cygwin)","fromName":"Marius Storm-Olsen","fromEmail":"mstormo@gmail.com","sentAt":"2009-10-02T08:07:10Z","receivedAt":"2009-10-02T08:07:10Z","isPatch":false,"sender":{"key":"mstormo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1500?v=4"},"body":"Ramsay Jones said the following on 01.10.2009 19:11:\n> Hi Marius,\n> \n> I know that I'm somewhat late to comment on your recent MSVC\n> build patches, but I was busy at the time; better late than\n> never... maybe ;-)\n> \n> While the patches were traversing the list, I was feeling\n> somewhat nervous about the effect of the patches on the\n> cygwin build; in fact I remember thinking that they had\n> *probably* broken the build. But I was busy...\n> \n> Well I finally found time, yesterday, to take a closer look.\n> I spent 10-15 minutes squinting at the code in order to\n> convince myself that you had in fact *not* broken the cygwin\n> build. :)\n...\n> [Note: I was a little surprised that it got that far, since I didn't\n> expect it to find the zlib header files. However, I have set the\n> INCLUDE environment variable which msvc is respecting! yeah, a bit old\n> fashioned!  Having also set the LIB environment variable, I was then\n> a bit surprised that the linker didn't find the library; until I\n> noticed that my library is called libz.lib *not* zlib.lib!]\n...\nClone the git://repo.or.cz/msvcgit.git, and run the \nsetup_32bit_env.cmd script in there, and you should have everything \nyou need to both compile and link Git with MSVC.\n\n> Note that the patch below includes some line-wrapping which you can\n> ignore if you like, it just makes the Makefile easier to read.\n> The only change that matters is inserting a space between -DWIN32 and\n> -D_CONSOLE.\n> \n> Anyway, the point is *not* to get the msvc build to work for me; rather\n> it is to understand why the build *works* for you. ;-)\n\nFirst of all, thanks for the thorough report! :)\nSecond, I just recompiled, and it magically works for me. Why is a \ngood question, since I also think it shouldn't at this point. The \n_WIN32 define is added by the compiler, and the WIN32 is added by \nwindows.h, so our define guards *should* be testing for the _WIN32 define.\n\nTo how the guarded code reacts, I preprocessed the run-command.c with \nboth version of the command line, and the result was the same:\n\n( 9:54:49 - D:\\msvc\\git)\n > cl -E ... -DWIN32-D_CONSOLE ... run-command.c | grep run_thread\nrun-command.c\nstatic unsigned __stdcall run_thread(void *data)\n         async->tid = (HANDLE) _beginthreadex(((void *)0), 0, \nrun_thread, async, 0, ((void *)0));\n\n( 9:55:43 - D:\\msvc\\git)\n > cl -E ... -DWIN32 -D_CONSOLE ... run-command.c | grep run_thread\nrun-command.c\nstatic unsigned __stdcall run_thread(void *data)\n         async->tid = (HANDLE) _beginthreadex(((void *)0), 0, \nrun_thread, async, 0, ((void *)0));\n\nSo, obviously, some magic in there is making it work for me. I have a \nhard time locating the magic in question though. :-/\nThat being said, does adding the space between the defines fix the \nMSVC compilation using Cygwin's GNU Make? It's none-the-less a correct \npatch, so you get an ack from me. Thanks!\n\nAcked-by: Marius Storm-Olsen <mstormo@gmail.com>\n\n--\n.marius\n"},{"id":"124119","messageId":"81b0412b0910020123j13c74497w874e301c38cddec9@mail.gmail.com","threadId":"21107","inReplyTo":"4AC5B4AE.5070307@gmail.com","subject":"Re: MSVC build broken (on cygwin)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-10-02T08:23:19Z","receivedAt":"2009-10-02T08:23:19Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"MSVC (all versions) define a compiler specific _MSC_VER, if that's of any use.\n"},{"id":"124125","messageId":"4AC5BEA6.5000102@gmail.com","threadId":"21107","inReplyTo":"81b0412b0910020123j13c74497w874e301c38cddec9@mail.gmail.com","subject":"Re: MSVC build broken (on cygwin)","fromName":"Marius Storm-Olsen","fromEmail":"mstormo@gmail.com","sentAt":"2009-10-02T08:49:42Z","receivedAt":"2009-10-02T08:49:42Z","isPatch":false,"sender":{"key":"mstormo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1500?v=4"},"body":"Alex Riesen said the following on 02.10.2009 10:23:\n> MSVC (all versions) define a compiler specific _MSC_VER, if that's of any use.\n\nIn this case it was define guards to let both MSVC and MinGW through \n:) Both use _WIN32 and WIN32, which Cygwin gcc normally doesn't, \nunless, as Ramsay said, you specify -mno-cygwin, or include windows.h \napparently.\n\nMaybe we should allow Cygwin to also include the LEAN_AND_MEAN \nwindows.h in git-compat-util.h, and rather fix up the guards to \ncleanly differ between Cygwin and non-Cygwin on Windows?\n\nApparently, nothing is broken in neither Cygwin, MinGW or MSVC after \nRamsays whitespace fix, but I'm sure it might get hairy later, if/when \nwe get more Windows contributions. Keeping the guards right could get \ntricky.\n\nSo, something like this maybe, in git-compat-util.h:\n\n#if defined(__MINGW32__) || defined(_MSC_VER)\n#  defined API_WIN32\n#  defined OS_WINDOWS\n#elif defined(__CYGWIN__)\n#  defined API_POSIX\n#  defined OS_WINDOWS\n#else\n#  defined API_POSIX\n#endif\n\nSo, then we can use #ifdef API_WIN32 when using the Win32 API is the \nonly option/preferred for MinGW or MSVC; and use #ifdef OS_WINDOWS \nwhen there are things that affect all the Windows builds.\n\nOpinions?\n\n--\n.marius\n"},{"id":"124189","messageId":"4AC7A7BC.5070608@ramsay1.demon.co.uk","threadId":"21107","inReplyTo":"4AC5B4AE.5070307@gmail.com","subject":"Re: MSVC build broken (on cygwin)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2009-10-03T19:36:28Z","receivedAt":"2009-10-03T19:36:28Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Marius Storm-Olsen wrote:\n> ...\n> Clone the git://repo.or.cz/msvcgit.git, and run the \n> setup_32bit_env.cmd script in there, and you should have everything \n> you need to both compile and link Git with MSVC.\n> \n\nHmm, I'm trying to avoid YASORD (Yet Another Set Of Redundant\nDependencies ;-)  On my laptop, I currently have 4 zlib installations,\n5 openssl installations, 3 iconv's ...\n\nAs I said earlier (see below), I'm not so interested in getting the\nmsvc build to work for me, rather than understand why it works for you,\nsince it should not work!\n\nHaving said that, I *may* try to get it working on my cygwin\ninstallation. However, I'm much more likely to make some changes to\nthe build/Makefile to allow the dependent libraries to be installed\nin different locations :) There is nothing wrong with my zlib at\nC:\\zlib.\n\n>> Anyway, the point is *not* to get the msvc build to work for me; rather\n>> it is to understand why the build *works* for you. ;-)\n> \n> First of all, thanks for the thorough report! :)\n\nYou're welcome.\n\n> Second, I just recompiled, and it magically works for me. Why is a \n> good question, since I also think it shouldn't at this point. The\n\nOh, you *really* don't want \"magic\" to be the answer... :P\n\n> So, obviously, some magic in there is making it work for me. I have a \n> hard time locating the magic in question though. :-/\n\nWhich shell are you using? MSYS-bash?\nWhich make are you using? MSYS-GNU?\nWhich Perl are you using? ActiveState? MSYS?\n\nI'm using cygwin 1.5.22, along with the cygwin versions of\nbash 3.2, GNU make 3.81, perl 5.8.7\n\nI noticed that the clink.pl script was not returning the correct exit\ncode to the Makefile, which is why I ended up snipping 940 lines of\noutput from the earlier #error demonstration; the Makefile does not\nnotice when the compile exits with an error.\n\nIn order to fix this issue for me, I made the following change:\n\n-- >8 --\ndiff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl\nindex 0ffd59f..3e4e501 100644\n--- a/compat/vcbuild/scripts/clink.pl\n+++ b/compat/vcbuild/scripts/clink.pl\n@@ -45,4 +45,18 @@ if ($is_linking) {\n \tpush(@args, @cflags);\n }\n #printf(\"**** @args\\n\");\n-exit system(@args);\n+\n+system(@args);\n+\n+if ($? == -1) {\n+\tprint \"clink.pl: failed to execute: $!\\n\";\n+\texit 1;\n+}\n+elsif ($? & 127) {\n+\tprintf \"clink.pl: child died with signal %d%s\\n\",\n+\t\t($? & 127), ($? & 128) ? ', coredump.' : '.';\n+\texit 1;\n+}\n+\n+exit $? >> 8;\n+\n-- >8 --\n\nSee \"perldoc -f system\" for more explanation of the above. This is\nhow it works on unix and unix-alike systems, so this may not work\ntoo well on (say) ActiveState Perl; Dunno. Also, according to this\ndocumentation, the form of the call to system() should result in a\ncall to an exec function, rather than using a shell; this may or\nmay not be true on other platforms.\n\nHaving fixed that problem, I modified clink.pl again so that it\nwould run args.exe rather than cl.exe; this allowed me to see,\nusing: make -> perl -> \"system()\" -> args.exe, just what will be\npassed to the compiler.\n\nJust in case you can't guess, create args.exe from:\n\n    $ cat -n args.c\n         1\t#include <stdio.h>\n         2\t\n         3\tint main(int argc, char *argv[])\n         4\t{\n         5\t\tint i;\n         6\t\n         7\t\tfor (i=0; i< argc; i++) {\n         8\t\t\tprintf(\"argv[%d] = '%s'\\n\", i, argv[i]);\n         9\t\t}\n        10\t\texit(1);\n        11\t}\n        12\t\n    $ \n\nand put it somewhere in your path (~/bin for me).\n\n    $ make MSVC=1\n    GIT_VERSION = 1.6.5.rc1.38.gb4f27.dirty\n        * new build flags or prefix\n        CC fast-import.o\n    argv[0] = 'args'\n    argv[1] = '-Fofast-import.o'\n    argv[2] = '-c'\n    argv[3] = '-nologo'\n    argv[4] = 'fast-import.c'\n    argv[5] = '-I.'\n    argv[6] = '-I../zlib'\n    argv[7] = '-Icompat/vcbuild'\n    argv[8] = '-Icompat/vcbuild/include'\n    argv[9] = '-DWIN32-D_CONSOLE'\n    [...snipped...]\n    argv[56] = '-Icompat/regex'\n    make: *** [fast-import.o] Error 1\n\nPerhaps you could try a similar exercise?\n\nHmm, do you have any funny environment variables set which msvc is\npicking up? \nOh, what about the CL variable?\n\n> That being said, does adding the space between the defines fix the \n> MSVC compilation using Cygwin's GNU Make? It's none-the-less a correct \n> patch, so you get an ack from me. Thanks!\n> \n> Acked-by: Marius Storm-Olsen <mstormo@gmail.com>\n> \n\nThanks!\n\nATB,\nRamsay Jones\n"},{"id":"124188","messageId":"4AC7AEB9.3030404@ramsay1.demon.co.uk","threadId":"21107","inReplyTo":"4AC5BEA6.5000102@gmail.com","subject":"Re: MSVC build broken (on cygwin)","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2009-10-03T20:06:17Z","receivedAt":"2009-10-03T20:06:17Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Marius Storm-Olsen wrote:\n> Apparently, nothing is broken in neither Cygwin, MinGW or MSVC after \n> Ramsays whitespace fix, but I'm sure it might get hairy later, if/when \n> we get more Windows contributions. Keeping the guards right could get \n> tricky.\n> \n\nRight! Thus my earlier nervousness. :P\n\n> So, something like this maybe, in git-compat-util.h:\n> \n> #if defined(__MINGW32__) || defined(_MSC_VER)\n> #  defined API_WIN32\n> #  defined OS_WINDOWS\n> #elif defined(__CYGWIN__)\n> #  defined API_POSIX\n> #  defined OS_WINDOWS\n> #else\n> #  defined API_POSIX\n> #endif\n> \n\nThis is a much better idea.\n\nNote that I also have Digital-Mars C/C++ 8.50, Open Watcom C/C++ 1.8\nand lcc 4.2 installed. So, lets add to our previous tests:\n\nDigital-Mars:\n\n    $ dmc hello.c\n    link hello,,,user32+kernel32/noi;\n\n    $ ./hello.exe\n    _WIN32\n    WIN32\n    Hello world\n    $ \n\n    $ dmc -DIW_H hello.c\n    link hello,,,user32+kernel32/noi;\n\n    $ ./hello.exe\n    _WIN32\n    WIN32\n    Hello world\n    $ \n\n    $ dmc -DWIN32-D_CONSOLE hello.c\n    Command line error: bad -D switch, need '=' after macro name--- errorlevel 1\n    $ \n\nOpen Watcom:\n\n    $ wcl386 hello.c\n    [...compiler output snipped...]\n    $ ./hello.exe\n    _WIN32\n    Hello world\n    $ \n\n    $ wcl386 -DIW_H hello.c\n    [...compiler output snipped...]\n    $ ./hello.exe\n    _WIN32\n    Hello world\n    $ \n\n    $ wcl386 -DWIN32-D_CONSOLE hello.c\n    Open Watcom C/C++32 Compile and Link Utility Version 1.8\n    Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.\n    Source code is available under the Sybase Open Watcom Public License.\n    See http://www.openwatcom.org/ for details.\n           wcc386 hello.c  -DWIN32 -D_CONSOLE\n    Open Watcom C32 Optimizing Compiler Version 1.8\n    Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.\n    Source code is available under the Sybase Open Watcom Public License.\n    See http://www.openwatcom.org/ for details.\n    hello.c: 25 lines, included 757, 0 warnings, 0 errors\n    Code size: 52\n           wlink @__wcl__.lnk\n    Open Watcom Linker Version 1.8\n    Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.\n    Source code is available under the Sybase Open Watcom Public License.\n    See http://www.openwatcom.org/ for details.\n    loading object files\n    searching libraries\n    creating a Windows NT character-mode executable\n    $ ./hello.exe\n    _WIN32\n    WIN32\n    Hello world\n    $ \n[Note: I didn't snip the compiler output here so that you could see that\nthe Watcom driver program had \"fixed\" the malformed -Define and passed\nit as two separate parameters to the compiler proper!]\n\nAlso note that Open Watcom is currently being ported to Linux, I *think*\nDigital-Mars already has a Linux version and lcc does have a Linux\nversion. However, I think it's reasonably safe to assume we won't see a\nLinux version of msvc.\n\nSo, I think something like this in git-compat-util.h:\n\n#if defined(_WIN32) && !defined(__CYGWIN__)\n# define WIN32_API\n# define WIN32_LEAN_AND_MEAN\n# include <winsock2.h>\n# include <windows.h>\n#endif\n\nand replace all #if(n)def WIN32|_WIN32 with #if(n)def WIN32_API.\n\nThe only use of the <windows.h> header by cygwin can be moved\ninto compat/cygwin.c. (I don't much like cygwin using the\nWin32 API anyway!)\n\n> So, then we can use #ifdef API_WIN32 when using the Win32 API is the \n> only option/preferred for MinGW or MSVC; and use #ifdef OS_WINDOWS \n> when there are things that affect all the Windows builds.\n> \n> Opinions?\n\nsee above. I don't think OS_WINDOWS is necessary.\n\nAnyway, *something* like this would be an improvement.\n\nATB,\nRamsay Jones\n"},{"id":"124191","messageId":"4AC7B42B.8020506@gmail.com","threadId":"21107","inReplyTo":"4AC7AEB9.3030404@ramsay1.demon.co.uk","subject":"Re: MSVC build broken (on cygwin)","fromName":"Marius Storm-Olsen","fromEmail":"marius@storm-olsen.com","sentAt":"2009-10-03T20:29:31Z","receivedAt":"2009-10-03T20:29:31Z","isPatch":false,"sender":{"key":"marius@storm-olsen.com","avatar":"https://avatars.githubusercontent.com/u/1500?v=4"},"body":"Ramsay Jones said the following on 03.10.2009 22:06:\n> Marius Storm-Olsen wrote:\n>> So, something like this maybe, in git-compat-util.h:\n>>\n>> #if defined(__MINGW32__) || defined(_MSC_VER)\n>> #  defined API_WIN32\n>> #  defined OS_WINDOWS\n>> #elif defined(__CYGWIN__)\n>> #  defined API_POSIX\n>> #  defined OS_WINDOWS\n>> #else\n>> #  defined API_POSIX\n>> #endif\n> \n> This is a much better idea.\n\nOK, I'll write up a patch, tomorrow or Monday.\n\n...\n> So, I think something like this in git-compat-util.h:\n> \n> #if defined(_WIN32) && !defined(__CYGWIN__)\n> # define WIN32_API\n> # define WIN32_LEAN_AND_MEAN\n> # include <winsock2.h>\n> # include <windows.h>\n> #endif\n\nI agree with this one. Send a patch, and I'll ack.\n\n\n> and replace all #if(n)def WIN32|_WIN32 with #if(n)def WIN32_API.\n\nOk, I might look into that too then.\n\n\n> The only use of the <windows.h> header by cygwin can be moved\n> into compat/cygwin.c. (I don't much like cygwin using the\n> Win32 API anyway!)\n\nI don't have Cygwin installed, so I won't touch this one.\n\n\n>> So, then we can use #ifdef API_WIN32 when using the Win32 API is the \n>> only option/preferred for MinGW or MSVC; and use #ifdef OS_WINDOWS \n>> when there are things that affect all the Windows builds.\n>>\n>> Opinions?\n> \n> see above. I don't think OS_WINDOWS is necessary.\n\nWell, it was mostly intended where we'd have code/algorithms which are \nplatform specific, and not really compiler specific; such as the *stat() \noptimizations. They could probably be joined into an OS_WINDOWS section, \nwith a POSIX_API hunk for the Cygwin fallbacks.\n\nNot really important though. Hopefully there won't be too much platform \nspecific stuff anyways.\n\n--\n.marius\n"}]}