From: Oliver B. <oli...@go...> - 2014-03-31 02:09:55
|
Hi William! On 22.03.2014 00:51, Oliver Buchtala wrote: >> >> That test requires the wrappers to be compiled as C. Looks like the >> JavaScript wrappers are compiled as C++ even for C code. Presumably >> there is only a C++ interface for v8/node? This info should go into >> the docs - it can cause some problems because not all C code can >> compile as C++ code. Fix the test-case like it is 'fixed' for octave >> in the .i file - just don't test it for javascript! > Done. >> Are there 3 different preprocessor macros defined for the 3 different >> javascript engines so that we can detect which engine SWIG is >> generating wrappers for? I think that is needed if they aren't in >> place. Document them in Doc/Manual/Preprocessor.html like other >> languages. >> Done. I added the following: SWIGJAVASCRIPT Defined when using Javascript SWIG_JAVASCRIPT_JSC Defined when using Javascript for JavascriptCore SWIG_JAVASCRIPT_V8 Defined when using Javascript for v8 or node.js There is an extra #define for nodejs `BUILDING_NODE_EXTENSION` which is necessary to control node.js. But it is actually not swig specific so I did not add it here. > - Can you fix that testcases so that Travis testing goes green? Shout > if you need any more help. > Done. >> - .travis.yml: Can you modify to install just the one appropriate JS >> buildengine at a time, so there will be 3 separate sudo apt-get >> installs. Currently all 3 get installed even though only one of them >> is tested at a time. This will make sure each install works >> independently and make the testing a bit faster. > Done. Now, I am having two remaining test-cases: > checking testcase enum_forward under javascript (v8) > enum_forward_wrap.cxx:1365:6: error: use of enum ‘ForwardEnum3’ without previous declaration > enum ForwardEnum3; > checking testcase nested_structs under javascript (v8) > nested_structs_wrap.cxx: In function ‘int nestedByVal(Named)’: > nested_structs_wrap.cxx:1380:5: error: ‘s’ has incomplete type > int nestedByVal(struct Named s) { return s.val; } ^ I'll investigate what might be the problem here. If you have a hint let me know. >> I am totally not sure about the cmake stuff... >> It is simply still not feasible to make the test-suite work with cmake. >> PITA. >> Let us create a branch that we would rebase every once in a while so >> that people can use >> to e.g. build conveniently under windows. >> > I'd like to one day see a good working CMakeLists.txt file in the > master even if it just builds the swig exe at a minimum. I don't know > what state this is in your repo, but i'll look at it as a separate > patch after the JS merge if it is in good shape. It should use a > common (to automake) file containing the SWIG source files. I pushed my CMake configuration to a new branch 'cmake'. We can discuss how to proceed with it in future. >> The gdb things... I don't know... maybe the same strategy? (is there >> real interest?) > I liked these gdb debuggers when I looked at it a year or two back. I > think we should keep them as an option to the current Tools/swig.gdb > as they should be a whole lot better. > Likewise, I pushed this work to an extra branch 'gdb_pretty_printers'. I need to take another round to check if it is still working and to add some documentation. Cheers, Oliver |