Hi Ari, Which SWIG version have you been testing with?
Converting IntPtr to string doesn't seem to be a good solution. We should do something like what we do for ReadRaster which also use AddrOfPinnedObject(). I'm trying to reproduce this. Best regards, Tamas 2015-05-29 9:11 GMT+02:00 Ari Jolma <ari.jo...@gmail.com>: > In my fork I've now added mono-mcs into the travis test machine and "make > test" to CSharp. The build & tests all work. > > https://travis-ci.org/OSGeo/gdal/builds/64450000 > > However, one fix I did for the CSharp bindings is most probably wrong > (convert return value of handle.AddrOfPinnedObject() to char *) > > > https://github.com/ajolma/gdal/commit/6509ef06d6f89d99c446300e4f4a63b65613911e > > Tamas, do you have an idea for this? > > There are a lot of #if ... #endif's in for example ogr.i to limit > %feature("kwargs"), this is due to a swig bug, which is fixed in 3.03 so we > need to leave them in for now. > > https://github.com/swig/swig/issues/242 > > There's a lot still to do to cleanup the common interface files but how do > you feel, is there a chance that this is accepted into the trunk (and 2.1)? > I'd also love to have a policy for developing the bindings and working test > codes for all maintained languages. A rule could be that the use of #if ... > #endif in common files needs a good justification and commits, which do not > cause test codes to fail are ok per se. > > Best, > > Ari > > On 26.05.2015 13:53, Tamas Szekeres wrote: > > Is that a requirement that the bindings should work well with all SWIG > versions or that the generated wrappers should work just fine? > > Formerly I have been thinking that we should support all versions, but > it took large amount of extra efforts to work around all incompatible > changes what SWIG introduces all the time even with the minor releases. > Regarding to SWIG C# the earlier versions produced definitely wrong code > and I had implement quite some generic stuff in the bindings (for example > to work around the early garbage collection issues). I see some > enhancements in the recent versions in this regard, but I'm not sure if I > can completely remove these additions to get a stable and consistent build. > > Tamas > > > > 2015-05-26 11:09 GMT+02:00 Ari Jolma <ari.jo...@gmail.com>: > >> 26.05.2015, 11:38, Even Rouault kirjoitti: >> >>> Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit : >>> >>>> Hi Ari, >>>> >>>> I haven't tried to compile that with mono for quite a long time. I'll >>>> give >>>> it a try. >>>> >>>> However we did not follow the latest changes in the SWIG implementation >>>> with the bindings, so I'd try with an earlier version (ie. 1.3.39) to >>>> generate the wrappers. >>>> >>> I can confirm that I can compile the CSharp bindings on Linux with SWIG >>> 1.3.40 >>> (and run the tests), but I get the same error as Ari with SWIG 2.0.X >>> >>> As far as I know, Java and Python bindings build and run equaly well >>> with SWIG >>> 1.3.40 or 2.0.X (although there's a Unix makefile hack to have Python 3.2 >>> compat, conditionnaly applied with SWIG 1.3.40, that is no longer needed >>> with >>> SWIG 2.0.4 or later) >>> >> >> Swig 1.3.39 seems questionable. Just look at the download amounts at >> sourceforge. 1.3.39 one download and 1.3.40 148 downloads per week. >> >> However, 1.3.39 does *not* put the PVINVOKE() method twice into the >> PVINVOKE.cs file. >> >> >>> May be we should consider including the generated >>>> wrappers in gdal instead of let the users to use different versions with >>>> different results. >>>> >>> It would be good if we could have a common SWIG version that works for >>> all the >>> bindings. So currently it seems to be 1.3.40 ? >>> >>> Regarding putting the generated wrappers in SVN, that's already what we >>> do for >>> Python. We could also just include the generated wrappers in the >>> tarballs. >>> >> >> IMO "users" = people who use ready-made packages. Developers and >> packagers should be intelligent enough to use development tools. I don't >> like the idea of having generated files in source repositories. I'm also of >> the opinion that there should be a really good reason to use an old version >> of a common tool. And at least in my Linux (Mint, Maya - hmm, that seems >> already pretty old, I should upgrade) swig 2.0.11 is the current. But >> that's just me I guess. >> >> Ari >> >> >>> Even >>> >>> >> > >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev