[gdal-dev] CSharp bindings question

[Tamas Szekeres]

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.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>:
>
>> 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/2a1ad9fa/attachment-0001.html>