[gdal-dev] CSharp bindings question

[Ari Jolma]

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/81bb7704/attachment.html>