Opened 13 years ago

Closed 6 years ago

#2207 closed enhancement (wontfix)

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

Reported by: fbausch Owned by: tamas
Priority: normal Milestone:
Component: CSharpBindings Version: unspecified
Severity: normal Keywords:
Cc: tamas, Mateusz Łoskot, warmerdam, hobu

Description

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?

Attachments (2)

nmake-vc.opt (13.4 KB) - added by fbausch 13 years ago.
makefiles.zip (12.0 KB) - added by fbausch 13 years ago.
zip archive of six text files

Download all attachments as: .zip

Change History (13)

comment:1 Changed 13 years ago by warmerdam

Cc: tamas Mateusz Łoskot warmerdam added

comment:2 Changed 13 years ago by tamas

Cc: hobu added
Component: SWIG (all bindings)CSharpBindings
Owner: changed from hobu to tamas
Version: 1.5.0unspecified

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.

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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.

Changed 13 years ago by fbausch

Attachment: nmake-vc.opt added

Changed 13 years ago by fbausch

Attachment: makefiles.zip added

zip archive of six text files

comment:5 Changed 13 years ago by 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.

comment:6 in reply to:  5 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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.

comment:8 in reply to:  7 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by 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

comment:10 in reply to:  9 Changed 12 years ago by 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

comment:11 Changed 6 years ago by Jukka Rahkonen

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.