On 21 March 2013 12:39, Keith W <keith.w...@gmail.com> wrote: > Hi Cliff > > The winsock.h change resolved the remaining C++ compilation errors. > Will this be part of your patch? > > The next error I see is still from a java step within > binding/java/CMakeLists.txt - a problem with determining a list of > java source files generated by swig. Do you see the same? This is > code that Phil and I contributed so we'll take a look - unless you > have already started.
I see the issue. The colon separating windows drive is being treated as if it were a path separator and this is causing the scipt to bomb out. I'll raise a Jira and fix the CMakeLists.txt. > > "X:\src\proton\build\ALL_BUILD.vcxproj" (default target) (1) -> > "X:\src\proton\build\proton-c\bindings\java\proton-jni.vcxproj" (default > target > ) (7) -> > "X:\src\proton\build\proton-c\bindings\java\proton-jni-sourcefile-list.vcxproj" > (default target) (8) -> > (CustomBuild target) -> > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets > (151,5): error MSB6006: "cmd.exe" exited with code 1. > [X:\src\proton\build\prot > on-c\bindings\java\proton-jni-sourcefile-list.vcxproj] > > 0 Warning(s) > 1 Error(s) > > Time Elapsed 00:00:48.50 > > regards, Keith > > On 20 March 2013 16:57, Cliff Jansen <cliffjan...@gmail.com> wrote: >> Hi Keith, >> >> Sorry, the compile errors you see on Windows should go away with the >> following in java.i: >> >> 26a27,29 >>> #if defined(_WIN32) && ! defined(__CYGWIN__) >>> #include <winsock2.h> >>> #endif >> >> I am able to generate protocol.h and encodings.h on my Windows systems >> (a range of XP -> Windows 8, VS2008 -> VS2012, 32/64 bit). I am using >> fairly up to date versions of python, cmake and swig. So I am not >> sure why it is failing for you. >> >> Note that Windows support is still a work in progress. For 0.4 I only >> have completed building proton-c on Windows and the limited ctest >> infrastructure (i.e. syntax errors and CMakeLists.txt). Some >> proton-test tests fail and investigation is pending. >> >>> I wonder if it is possible to move your workaround into its own .i >>> file which would be located alongside codec.h? java.i would then >>> include it using a %import. This approach would also facilitate >>> sharing with the other bindings (surely they would need the same >>> solution??). >> >> Let me think about that or perhaps another way to address your >> (sensible) concern and get back to you later today or tomorrow. >> >> Cliff >> >> On Wed, Mar 20, 2013 at 11:33 AM, Keith W <keith.w...@gmail.com> wrote: >>> Hello Cliff >>> >>> I too share your dislike of my suggested change to code.h:) I do >>> prefer your alternative despite the duplication. However I worry that >>> the copy - deep within the java bindings tree would be overlooked when >>> changes are made to codec.h and the two would diverge, leading to >>> obscure defects. >>> >>> I wonder if it is possible to move your workaround into its own .i >>> file which would be located alongside codec.h? java.i would then >>> include it using a %import. This approach would also facilitate >>> sharing with the other bindings (surely they would need the same >>> solution??). >>> >>>> I had just got this working yesterday on Linux and was trying a Windows >>>> build before posting a review. It fails in cmake scripts working with >>>> windows paths (and maybe other problems). >>> >>> I see an issue on Windows (Windows 7/MS Visual Studio 2010/Python >>> 2.7.3) with the generation of protocol.h and encodings.h. It behaves >>> as if the cmd-shell is ignoring the redirection (>). I see the >>> generated file flash by in cmd window and no .h is written. I'm >>> working around by executing: >>> >>> python X:/src/proton/proton-c/env.py PYTHONPATH=X:/src/proton/proton-c >>> python X:/src/proton/proton-c/src/protocol.h.py > >>> X:/src/proton/buildwin/proton-c/protocol.h >>> python X:/src/proton/proton-c/env.py PYTHONPATH=X:/src/proton/proton-c >>> python X:/src/proton/proton-c/src/codec/encodings.h.py > >>> X:/src/proton/buildwin/proton-c/encodings.h >>> >>> Do you see this? My windows box behaves oddly at the best of times. >>> >>> On Windows I still see a number of C++ compilation errors from >>> javaJAVA_wrap.cxx. Do you see these? I haven't started to >>> investigate yet. >>> >>> 11>X:\src\proton\proton-c\include\proton/driver_extras.h(40): error >>> C2146: syntax error : missing ';' before identifier 'pn_socket_t' >>> 11>X:\src\proton\proton-c\include\proton/driver_extras.h(40): error >>> C4430: missing type specifier - int assumed. Note: C++ does not >>> support default-int >>> 11>X:\src\proton\proton-c\include\proton/driver_extras.h(40): error >>> C4430: missing type specifier - int assumed. Note: C++ does not >>> support default-int >>> 11>X:\src\proton\proton-c\include\proton/driver_extras.h(53): error >>> C2061: syntax error : identifier 'pn_socket_t' >>> 11>X:\src\proton\proton-c\include\proton/driver_extras.h(63): error >>> C2061: syntax error : identifier 'pn_socket_t' >>> 11>javaJAVA_wrap.cxx(1062): warning C4018: '<' : signed/unsigned mismatch >>> 11>javaJAVA_wrap.cxx(1089): warning C4018: '<' : signed/unsigned mismatch >>> 11>javaJAVA_wrap.cxx(7754): error C2146: syntax error : missing ';' >>> before identifier 'arg2' >>> 11>javaJAVA_wrap.cxx(7754): error C2065: 'arg2' : undeclared identifier >>> 11>javaJAVA_wrap.cxx(7761): error C2065: 'arg2' : undeclared identifier >>> 11>javaJAVA_wrap.cxx(7761): error C2146: syntax error : missing ';' >>> before identifier 'jarg2' >>> 11>javaJAVA_wrap.cxx(7763): error C2065: 'arg2' : undeclared identifier >>> 11>javaJAVA_wrap.cxx(7772): error C2146: syntax error : missing ';' >>> before identifier 'arg2' >>> 11>javaJAVA_wrap.cxx(7772): error C2065: 'arg2' : undeclared identifier >>> 11>javaJAVA_wrap.cxx(7779): error C2065: 'arg2' : undeclared identifier >>> 11>javaJAVA_wrap.cxx(7779): error C2146: syntax error : missing ';' >>> before identifier 'jarg2' >>> 11>javaJAVA_wrap.cxx(7781): error C2065: 'arg2' : undeclared identifier >>> >>>> Let me know if you wish to tackle the remaining windows build issues. >>> >>> I can't offer to take these on firstly as my focus is Engine at >>> present, and C/C++ it is no longer my area of expertise (12 years of >>> rust). I will pitch in and help with any questions you may have with >>> the JNI aspects if I can. I am also in the process of getting this >>> build set up on Apache Jenkins. >>> >>> Kind regards, Keith >>>
