[Gdal-dev] Guidelines for the typemap usage for the SWIG bindings

[Tamas Szekeres]

2007/4/21, Ari Jolma <ari.jolma at tkk.fi>:
> I agree. If you can draft such an agreement that would be very welcome.
> I must say that I have a really hard time understanding what is going on
> in the swig bindings at any given place and time - somehow swig requires
> a perverse and a crooked way of thinking ;), not linear at all.
>

Ari,

I volunteer to make my initial offer in a week or two. But surely it
will require some further refinements considering the aspects of the
other languages I'm not familiar with.
But, indeed, SWIG requires a kind of obsession from the developer to
survive, often having to dig into the implementation to understand
what's going on behind the scenes. I guess no one can really
understand the whole stuff until making a full %feature-d language
implementation for it ;-).

> I used the #ifdef's you refer to below, as I did not know if the effect
> would be harmful for the other bindings or if they had such typemaps I
> was using/adding to the Perl bindings. BTW, that whole section is #if
> !defined(SWIGPYTHON) (!). I don't recall how I announced these things on
> the list, but I think my intention was that having the typemap applied
> for Perl only was only temporary solution.
>

One of my main objectives is that the developer could blindly add
working implementations for even the members having esoteric types of
the formal parameter list or the return value. Applying commonly
accepted typemaps for the GDAL/OGR datatypes would establish the
proper environment for this purpose. In addition many of the members
having unmapped types like SWIGTYPE_p_p_char would disappear
automatically from my (C#) side.
And there should be at least one doc for the bindings maintainers
including the "which typemaps are compulsory to implement" kind of
information inside.

Best regards,

Tamas