enhancements to SWIG config to support C# wrapper under Windows CE

[fbausch]

it would be nice to have a working C# wrapper for the CE version of the GDAL DLL - i've been working on this but without enough success - SWIG itself doesn't cleanly support CE yet, though i've seen some modifications to typemaps that get much of the job done. Perhaps someone with a better grasp of SWIG can get there with less pain than I?

[tamas]

I've already put some effort to achive this, but I hadn't enough time to finish all of the work. Actually the Compact Framework supports only a limited set of the features we use. We have to redesign how some of the types are marshaled between the C and the C# sides.

And we should also figure out the correct compilation flags to compile the C part of the interface or include the wrappers into the solution based mechanism that the WinCE port currently use.

[fbausch]

i've been working on this for a while now, and i am now well aware of what is missing from the .NETCF. i have some solutions for the marshalling, i think i have the appropriate compilation settings for both the C++ and C# code, and i have created separate makefiles for the SWIG CE build. i'd be happy to contribute back whatever i can produce - but i might do better on the GDAL-specific end if i saw the existing work.

[tamas]

It would be helpful if you could share your code (especially the working makefiles) you have. Then I'll take care of the integration. I'd also appreciate some testing efforts do discover the possible issues with the final implementation.

[fbausch]

zip archive of six text files

[fbausch]

Attached are six files to support building the WinCE version of the SWIG wrappers, based on the VC build setup. The CE process reuses as much as possible of the original setup, uses the same folders and many of the same makefiles. Which means the CE wrapper build will overwrite the VC wrapper build and vice versa.

(The x_y_name.ext notation means that the path is to be gdal-1.5.0/x/y/name.ext)

The build process has not replaced all the makefiles; some makefile.vc files are still used for the CE build, and they still reference nmake.opt. This plus the need for the correct version of port/cpl_config.h files mean that the build has to manage the VC and CE-specific versions of nmake.opt and port/cpl_config.h.

Thus there is swig-makefile.vc, the VC version which is therefore enhanced to overwrite the VC versions. And the original nmake.opt has correspondingly been renamed as nmake-vc.opt

Some of the make targets are commented out, since all i was interested in building was gdal, and not ogr or osr.

[tamas]

Thank you for sharing this. Are you using some special environment settings during the build?

Replying to fbausch:

Attached are six files to support building the WinCE version of the SWIG wrappers, based on the VC build setup. The CE process reuses as much as possible of the original setup, uses the same folders and many of the same makefiles. Which means the CE wrapper build will overwrite the VC wrapper build and vice versa.

(The x_y_name.ext notation means that the path is to be gdal-1.5.0/x/y/name.ext)

The build process has not replaced all the makefiles; some makefile.vc files are still used for the CE build, and they still reference nmake.opt. This plus the need for the correct version of port/cpl_config.h files mean that the build has to manage the VC and CE-specific versions of nmake.opt and port/cpl_config.h.

Thus there is swig-makefile.vc, the VC version which is therefore enhanced to overwrite the VC versions. And the original nmake.opt has correspondingly been renamed as nmake-vc.opt

Some of the make targets are commented out, since all i was interested in building was gdal, and not ogr or osr.

[fbausch]

sorry - i should have talked about this in the earlier post. i don't think i am relying on any environment settings - but the nmake-wince.opt file does have a hardwired GDAL_HOME path, and assumes/requires that the swigwin-1.3.33 folder is under the same folder as the gdal-1.5.0 folder and the wcelibcex-1.0 folder. default settings are for VS2005 and WindowsCE 5.0 (Windows Mobile 6 is my platform). i've been delaying the cleanup of these hacks until i got something working.

[tamas]

I have some doubts that we don't have to set any further environment variables to point to the correct SDK (eg. by setting the FrameworkDir to point to the compact framework sdk), or create a vcvarsCE.bat for each of the specific SDK-s. How can we support that properly in gdal? I'm tending to provide support for a Visual Studio solution based approach where the integration of the various SDK-s might be more trivial. I guess that's why Mateusz has dropped the makefile based builds for Visual Studio 2005.

Replying to fbausch:

sorry - i should have talked about this in the earlier post. i don't think i am relying on any environment settings - but the nmake-wince.opt file does have a hardwired GDAL_HOME path, and assumes/requires that the swigwin-1.3.33 folder is under the same folder as the gdal-1.5.0 folder and the wcelibcex-1.0 folder. default settings are for VS2005 and WindowsCE 5.0 (Windows Mobile 6 is my platform). i've been delaying the cleanup of these hacks until i got something working.

[fbausch]

More clarification - i do have to run vcvars32.bat in my shell to set up the microsoft environment for nmake. Setting up a Visual Studio solution would avoid that requirement - but it's really pretty trivial - as far as i can tell, it's only needed to establish the paths to nmake, cl and csc.

The more important configurations would probably have to be added to an nmake-*.opt file anyway - that is, the c++ and c# compile line parameters - which is where the references to the compact framework will be. I took an easy out and coded the compact framework references into the swig-csharp-makefile.wince. but that seems to be where the csc options were already being set for the Win32 version.

on the topic of typemaps needed to work around the compact framework, there are several issues i've been trying to deal with - 1) lack of HandleRef in the compact framework. 2) inability to marshal wide strings to ANSI strings into gdal. 3) inability to marshal ANSI strings to wide strings coming out of gdal. 4) inability to marshal string lists coming out of gdal.

to start, 1) can be approached by stripping out HandleRefs and just using IntPtr. there is apparently a SafeHandle implementation in the .NETCF - see ​http://thread.gmane.org/gmane.comp.programming.swig.devel/17303/focus=17305

[tamas]

I think that vcvars.bat would be somewhat SDK dependent so we cannot support this officially because of the number of the possible variations. But creating it property is one of the vital parts of the compilation. For example in my particilar case the following locations might be sufficient:

Path to the C compiler/linker: C:\Program Files\Microsoft Visual Studio 8\VC\ce\bin\x86_arm

Path to the C# compiler: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

Path to the .NET framework Class libraries: C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE

We should also determine the proper location of the INCLUDES and LIBS as well. That's really confusing.

I'm aware of the restrictions you reported, and there are some further issues (like callbacks and delegates) might cause problems at run-time. But many of them have already been addressed in my sandbox.

Replying to fbausch:

More clarification - i do have to run vcvars32.bat in my shell to set up the microsoft environment for nmake. Setting up a Visual Studio solution would avoid that requirement - but it's really pretty trivial - as far as i can tell, it's only needed to establish the paths to nmake, cl and csc.

The more important configurations would probably have to be added to an nmake-*.opt file anyway - that is, the c++ and c# compile line parameters - which is where the references to the compact framework will be. I took an easy out and coded the compact framework references into the swig-csharp-makefile.wince. but that seems to be where the csc options were already being set for the Win32 version.

on the topic of typemaps needed to work around the compact framework, there are several issues i've been trying to deal with - 1) lack of HandleRef in the compact framework. 2) inability to marshal wide strings to ANSI strings into gdal. 3) inability to marshal ANSI strings to wide strings coming out of gdal. 4) inability to marshal string lists coming out of gdal.

to start, 1) can be approached by stripping out HandleRefs and just using IntPtr. there is apparently a SafeHandle implementation in the .NETCF - see ​http://thread.gmane.org/gmane.comp.programming.swig.devel/17303/focus=17305

[Jukka Rahkonen]

Unlikely that Windows CE related bugs would be solved ever. Closing.