[gdal-dev] CSharp bindings question

[Even Rouault]

Hi Ari,

> 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/6509ef06d6f89d99c446300e4f4a63b656139
> 11e
> 
> 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

Good to know.

I did a try with your branch and looks generally good to me as far as Python 
and Java are concerned. Thanks for your efforts on this.

I found that the Python bindings no longer compile with SWIG 1.3.40, but 
that's not really an issue if can now move to later SWIG versions (and Python 
3 support in SWIG 1.3.X needed an hack, so that would be great if we don't 
need it anymore). I tried with SWIG 2.0.10 and works good (tested with Python 
3.1 since Travis already tests Python 2)

I tried the Java bindings and looked at the generated code. I notice that 3 
SWIGTYPE_p_**** Java classes are generated due to missing typemaps :
- SWIGTYPE_p_CPLErrorHandler: only used by a gdal.CPLPushErrorHandler() method 
that wasn't exposed before. We'd likely need to hide it. It would require 
otherwise defining the appropriate typemap for the callback of 
PushErrorHandler() but callback typemaps are generally involved.
- SWIGTYPE_p_long_long: only used by Feature.SetFieldInteger64List() that 
wasn't exposed before. I guess I should be able to figure out the needed 
typemap
- SWIGTYPE_p_unsigned_char : only used as the return type of 
gdal.HexToBinary(). This used to return byte[] before.

Those are minor issues that I could fix once it is merged.

> 
> 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)?

trunk as today is 2.0, so I think it would be more prudent if we wait for 2.0 
to have been branched off from trunk before committing this. If we commit that 
early in 2.1 dev cycle, we should have enough time to discover and address 
potential issues.

> 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

I think one of the main pattern is that I want to map a C function to SWIG 
(for the need of the language of my interest) and realize that it needs a new 
typemap. So I add it for the language, and protect it by #if #endif to avoid 
breaking compilation for other languages (definitly justified), or expose new 
methods with the default and non-working SWIGTYPE_p_XXXXX types generated by 
SWIG. In this later case, we could question if #if #endif is justified: 
exposing non working methods isn't really great, but that shouldn't break 
users' workflow, since they won't be able to use them in practice, so they can 
be later fixed without really creating compatibility problems.

As it might be difficult in practice to coordinate with all maintainers at the 
exact time were things are needed, perhaps we need some wiki page to document 
which new methods have been added and which languages are impacted, so that 
the maintainer can look at it when he has time and add the needed typemaps.

> and
> commits, which do not cause test codes to fail are ok per se.

Seems reasonable to me.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com