[mapserver-dev] RFC92 implementation caused breaking changes in SWIG bindings

[thomas bonfort]

Tamas,
The goal of the change was to start working on a public mapserver C api, by
only exposing opaque pointers to our future public header file.
What do you mean by "the typemaps for the corresponding objects are not
applied"? What trivial mapscript test can I run to check what needs to be
changed without resorting to revert this change just yet? (e.g. a trivial
test that I am running in all mapscripts compiled by cmake is: "map=new
mapObj(); print map.name;" and checking that I get 'MS'. Would that not be
an indication that the typemaps are in fact created?

--
thomas


On 30 March 2013 19:26, Tamas Szekeres <szekerest at gmail.com> wrote:

> I notice that the recent changes related to RFC92, specifically the commit
> 45b7dd0d44<https://github.com/mapserver/mapserver/commit/45b7dd0d44112f41a04362516ba6406702b50470>in mapserver.h messed up the SWIG interface generation completely.
>
> Actually some of the definitions have been changed, like:
>
> typedef struct {
> ...
> } labelObj;
>
> have been modified to:
>
> typedef struct labelObj {
>   ...
> };
>
> and we have an additional  typedef struct labelObj labelObj; in
> mapserver-api.h
>
> By using this form, SWIG doesn't recognize the type correctly and the
> typemaps for the corresponding objects are not applied. By using typedefs
>  doesn't seem to provide a solution for this problem.
>
> Not sure what was the reason of this change, but I'd eagerly support
> reverting to the original form until we find out how SWIG type-mapping
> would work correctly this way.
>
> Best regards,
>
> Tamas
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130331/e86fdcf1/attachment.html>