[gdal-dev] CSharp bindings question

Fri May 29 06:15:35 PDT 2015

On 29.05.2015 15:22, Tamas Szekeres wrote:
> Hi Ari,
>
> Which SWIG version have you been testing with?

Mostly with the one that's loaded by default into a new Ubuntu (travis) 
/ Mint (I have version 17 which is based on Ubuntu Trusty), both are 
2.0.11 I think.

>
> 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.

Yes I'm sure it is not, I just used it to make it compile. It is used 
only(?) by FileFromMemBuffer, which is not tested in CSharp tests (I'm 
not yet testing it in Perl bindings either).

Ari

>
> Best regards,
>
> Tamas
>
>
> 2015-05-29 9:11 GMT+02:00 Ari Jolma <ari.jolma at gmail.com 
> <mailto:ari.jolma at 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.jolma at gmail.com
>>     <mailto:ari.jolma at 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
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150529/d1b26e8a/attachment.html>