[Gdal-dev] Re: GDAL wince bindings?

[Tamas Szekeres]

2007/10/19, Asaf Ben-Nathan <asaf at ben-nathan.com>:
>
> I did indeed chat to you last week about this issue, and I've been
> researching it
> and trying to get things working since then. I was also a little unsure what
> you
> wanted me to send. My makefiles for the bindings are still not working
> properly,
> so only thing I have right now is the compiled version of GDAL under wince
> (which
> you guys have kindly supplied in your release) which compiles and works
> fine.
> I'm compiling using VS; did you want me to create makefiles for this build?
>

Asaf,

I considered you have a working makefile for the core GDAL project
(not the C# related stuff) which is not officially supported right now
by GDAL. I was wondering if you would share this option which I
consider as a more convenient way to start with (rather than using
solutions and project files).

I was raising that because Mateusz have reported previously that the
makefile based build approach cannot be supported easily and that's
why the solution based approach is currently supported. I think we
could start from this as well but it has a few disadvantages when
trying to incorporate the C# related stuff inside.


> The only thing I have managed to do so far is to take a very simple function
> compiled
> under wince and wrap it with SWIG so that it can be called from the compact
> framework, however this is only a very simplistic example and will not be of
> much use
> when we try to wrap the whole of GDAL. I encountered a few problems even
> with
> this simple test:
>
> 1) ThreadStaticAttribute wasn't recognized.
> 2) String mapping didn't work.
>
> I removed the offending code from the SWIG generated PINVOKE file and got
> the code working, but I believe we need some sort of reasonable workaround
> for these.
>

I appreciate your work. I'm a bit wondering about the threadstatic
stuff since it should be supported by the .NET CF as well. This option
is used because the exception is created by a callback that should be
preserved in a static variable until the function returns.

I consider using delegates for calling back to the managed code is not
supported by the framework and that's why the propagation of the
strings and exceptions won't work. However I think we could replace
that with some other options like using Marshal.PtrToStringAnsi
explicitly.


I like the idea around SafeHandle very much, since it could take care
of the ownership of the reference internally and it would simplify the
code we have now. But this option seems to be available only for .NET
CF 2.0 and it has a limited support for MONO as well. Therefore we'll
have to keep the 2 implementations side by side in the project.

>
>
> Thats all I have for now, I've emailed both of them to request any feedback
> or help they can give me. This
> conversation took place over a year ago so some of it may already be fixed
> by now, I won't know until they
> respond. I'm more than happy to help in any way I can, just let me know what
> you'd like me to work on, and
> keep in mind that I'm a SWIG noob :)
>

>From my side I'll make some tests using the required data types in a
sample project and the results can easily be incorporated to GDAL if
there's no critical problems about the feasibility. It would be quite
helpful to have a working makefile having all the required platform
dependent options included which is quite difficult starting to figure
out from scratch.


Best regards,

Tamas