[gdal-dev] Bindings
Hi, I've been trying to find a way to make the common SWIG interface files less concerned about languages and the whole system more flexible and understandable (which I see a prerequisite for further developments). My conclusion seems to be now that it is probably better to make the main files, what are now gdal.i, ogr.i etc., language specific and only the class files, now ColorTable.i, MajorObject.i, etc., and some other files (typedefs.i etc.) common. That way each language could compose the module as they like. For example in Perl I would like to get rid of Const, and a language could put all classes into one module (gdal) etc. This would at least require extracting remaining common material in gdal.i and ogr.i into new files. I'll test this in my github fork - which I've mentioned a couple of times already. But it will probably take some time due to summer etc. Any comments on this? This is again just internal reorganization and does not affect the APIs. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings
Hi Ari, Creating language specific main files would be fine for me. We could also add the language specific extensions at the bottom section (like gdal_csharp_extend.i) directly into the file. We should however make sure to update all relevant files if a common change is done in a language specific file. Best regards, Tamas 2015-06-04 16:35 GMT+02:00 Ari Jolma ari.jo...@gmail.com: Hi, I've been trying to find a way to make the common SWIG interface files less concerned about languages and the whole system more flexible and understandable (which I see a prerequisite for further developments). My conclusion seems to be now that it is probably better to make the main files, what are now gdal.i, ogr.i etc., language specific and only the class files, now ColorTable.i, MajorObject.i, etc., and some other files (typedefs.i etc.) common. That way each language could compose the module as they like. For example in Perl I would like to get rid of Const, and a language could put all classes into one module (gdal) etc. This would at least require extracting remaining common material in gdal.i and ogr.i into new files. I'll test this in my github fork - which I've mentioned a couple of times already. But it will probably take some time due to summer etc. Any comments on this? This is again just internal reorganization and does not affect the APIs. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
09.03.2015, 11:18, Even Rouault kirjoitti: Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I did this fork and made the changes in my copy. Then made a pull request and now it says that the Travis CI build passed. But I assume Java etc. are not tested by Travis? Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
I'm curious about the setup. Do you commit to github, which then commits to trac.osgeo.org/gdal or how is the system setup? Ari 09.03.2015, 15:31, Even Rouault kirjoitti: Le lundi 09 mars 2015 14:27:05, Ari Jolma a écrit : 09.03.2015, 11:18, Even Rouault kirjoitti: Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I did this fork and made the changes in my copy. Then made a pull request and now it says that the Travis CI build passed. But I assume Java etc. are not tested by Travis? The Java, Perl and Python bindings are tested by Travis. See .travis.yml at the root of the repository I've just added in Vagrant the ability to build the Java and CSharp bindings, as well as Perl and Python. It turns out that Swig 2.0.4 that comes with Ubuntu 12.04 isn't compatible with the CSharp bindings. So the .cpp files are generated by a manually compiled swig 1.3.40. But at runtime I get a linking failure. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
Le lundi 09 mars 2015 14:47:48, Ari Jolma a écrit : I'm curious about the setup. Do you commit to github, which then commits to trac.osgeo.org/gdal or how is the system setup? Regarding Travis, this is vaguely described at http://trac.osgeo.org/gdal/wiki/Buildbot Basically I've a cron job that use git-svn to mirror svn history into git Regarding my usual commits habits, I usually just svn commit. When I do development in git branches, I may use git svn dcommit to commit back into SVN, but you can only do that on your own git-svn mirror, not a fork of https://github.com/OSGeo/gdal. Rougly described at https://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow Otherwise I create a git patch and apply it in a SVN repository (with caution to manually svn add new files). Regarding Vagrant, this is described here: https://trac.osgeo.org/gdal/wiki/Vagrant Ari 09.03.2015, 15:31, Even Rouault kirjoitti: Le lundi 09 mars 2015 14:27:05, Ari Jolma a écrit : 09.03.2015, 11:18, Even Rouault kirjoitti: Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I did this fork and made the changes in my copy. Then made a pull request and now it says that the Travis CI build passed. But I assume Java etc. are not tested by Travis? The Java, Perl and Python bindings are tested by Travis. See .travis.yml at the root of the repository I've just added in Vagrant the ability to build the Java and CSharp bindings, as well as Perl and Python. It turns out that Swig 2.0.4 that comes with Ubuntu 12.04 isn't compatible with the CSharp bindings. So the .cpp files are generated by a manually compiled swig 1.3.40. But at runtime I get a linking failure. Ari -- 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
Re: [gdal-dev] Bindings and typemaps
Le lundi 09 mars 2015 08:08:34, Ari Jolma a écrit : 08.03.2015, 23:49, Even Rouault kirjoitti: Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit : Ari, Your proposal looks reasonable (but I don't pretend mastering SWIG and anticipating all side effects) and you can experiment with that if you wish. Please make sure to test the 4 supported languages. If there are breakage you don't know how to fix, it will require coordination with me and Tamas and that should perhaps be done through a ticket with a patch, or a dedicated branch. Wouldn't the whole thing be best to be a branch from the beginning. Yes probably. If I branch the whole swig tree like this http://emilsblog.lerch.org/2010/03/working-with-feature-branch-in.html then it would assumably be quite simple to test all the changes in all languages. Yes, I generally branch a whole repository, but a subtree might do too. Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I don't know how to test C# and Java bindings. Especially C# is probably out of what I can do. Ari 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
Re: [gdal-dev] Bindings and typemaps
08.03.2015, 23:49, Even Rouault kirjoitti: Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit : Ari, Your proposal looks reasonable (but I don't pretend mastering SWIG and anticipating all side effects) and you can experiment with that if you wish. Please make sure to test the 4 supported languages. If there are breakage you don't know how to fix, it will require coordination with me and Tamas and that should perhaps be done through a ticket with a patch, or a dedicated branch. Wouldn't the whole thing be best to be a branch from the beginning. If I branch the whole swig tree like this http://emilsblog.lerch.org/2010/03/working-with-feature-branch-in.html then it would assumably be quite simple to test all the changes in all languages. I don't know how to test C# and Java bindings. Especially C# is probably out of what I can do. Ari Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
09.03.2015, 11:18, Even Rouault kirjoitti: Le lundi 09 mars 2015 08:08:34, Ari Jolma a écrit : 08.03.2015, 23:49, Even Rouault kirjoitti: Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit : Ari, Your proposal looks reasonable (but I don't pretend mastering SWIG and anticipating all side effects) and you can experiment with that if you wish. Please make sure to test the 4 supported languages. If there are breakage you don't know how to fix, it will require coordination with me and Tamas and that should perhaps be done through a ticket with a patch, or a dedicated branch. Wouldn't the whole thing be best to be a branch from the beginning. Yes probably. I'll do that. IMO the goal would be to reduce language specific ifdefs from the general bindings, and remove unnecessary typedefs. For example there are a lot of #ifndef SWIGJAVA %feature( kwargs ) CopyLayer; #endif Is there a reason keywords arguments are not enabled with -keyword option for languages that support them? Ari If I branch the whole swig tree like this http://emilsblog.lerch.org/2010/03/working-with-feature-branch-in.html then it would assumably be quite simple to test all the changes in all languages. Yes, I generally branch a whole repository, but a subtree might do too. Or if you prefer Git, you could fork https://github.com/OSGeo/gdal I don't know how to test C# and Java bindings. Especially C# is probably out of what I can do. Ari Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bindings and typemaps
Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit :
Even,
It took me quite a while again to understand what goes on with Swig when
we %apply a typemap etc.
I think we could simplify the things quite a lot if we simply use
typedefs and then create typemaps for the return values.
For example CPLErr is never returned to the calling language (I think,
but it could in any case be defined by the language typemap), thus we
could simply define typemaps for it in language specific files instead
of repeating
%apply (IF_ERROR_RETURN_NONE) { (CPLErr) };
...
%clear (CPLErr);
in the include/*.i files.
Also sometimes GDAL has simple int instead of CPLErr, which is used as a
success/failure return value, then we could (like we already do) write
typedef int RETURN_NONE;
(actually we have also
typedef int OGRErr;
for SWIGCSHARP, which is invented for the same reason I assume)
and then define typemaps for the new type and skip again
%apply (IF_FALSE_RETURN_NONE) { (RETURN_NONE) };
...
%clear (RETURN_NONE);
which is overkill (and I believe I introduced that).
BTW, RETURN_NONE is not a good name, maybe use TRUE_OR_FALSE or
something more descriptive.
Ari,
Your proposal looks reasonable (but I don't pretend mastering SWIG and
anticipating all side effects) and you can experiment with that if you wish.
Please make sure to test the 4 supported languages. If there are breakage you
don't know how to fix, it will require coordination with me and Tamas and that
should perhaps be done through a ticket with a patch, or a dedicated branch.
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
