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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
