[Gdal-dev] Ruby Bindings Update

Sat Jun 24 23:11:30 EDT 2006

Brilliant! thanks for that I'll let you know how it goes
shoaib
On 6/24/06, Charlie Savage <cfis at savagexi.com> wrote:
> [Sorry, meant to copy this to the list the first time]
>
> Hey Shoaib,
>
>   > Thanks for that Charlie
>   >
>   > I would be interested in porting some of my python scripts that use
>   > gdal into ruby so i can start trying them in Rails.
>
>
> That would be great.
>
>   >
>   > Just looking through the gdalautotest/ruby, it only has OGR stuff
>   > there. I wouldn't mind helping out to create the ruby gdal tests.
>   >
>
> Interesting.  Under gdalautotest/ruby, you should see two directories -
> ogr and osr.  If not, then make sure you're uptodate with CVS (although
> I checked in the osr stuff in January, so that's probably not it).
>
>   > So pointers on where to start, such as the dependencies & how to run
>   > the gdal tests would be most welcome. I have got gdal-1.3.2 compiled
>   > with the ruby bindings
>
> Sure.  The way I would approach this (and what I did for ogr and osr):
>
> 1. Copy the gdalautotest\gcore directory and put the copy under
> gdalautotest\ruby\gcore.
>
> 2.  Open up one of the python files.
>
> 3.  I then start at the top and work my way down, translating the Python
> to Ruby (its not too hard, the languages are pretty close).  The reason
> I port the Python code is because its a lot easier than coming up with
> my own tests - and its a good baseline to make sure both languages are
> doing the same thing.
>
> 4.  When porting, follow Ruby naming schemes.  So someObject.someMethod
> becomes some_object.some_method (the swig bindings translate the names
> under the covers).
>
> 5.  I use Ruby's unit test framework - that means you don't have to port
> the bottom of each Python file which has some custom test running code.
>
> 6.  When ported, take the new Ruby file and name it tc_xxxx where tc is
> "test case"
>
> 7.  Create a ts_xxx where ts is "test suite"  Add your new test case to
> the test suite.  Obviously, you need just one ts file per directory.
>
> 9.  Run the test case, see what works and what doesn't work.
>
> As you do the port, most stuff should work.  But you will undoubtedly
> run into issues with the way SWIG exposes some of the API methods.
>
> The things to look out for:
>
> 1.  Some API methods return new objects, and Ruby must be told this.
> Hopefully you won't run into any of these since there was a lot of work
> getting this right in the SWIG bindings shared by all languages.  You'll
> know that you've got an issue if your test cases cause segmentation
> faults (these become particularly obvious when running a full test suite
> which gives everything time to blow up).
>
> 2.  There is also the inverse, you pass in an object as a parameter to
> an API method and it takes over ownership.  Once again, hopefully you
> won't run into this.  Once again, you'll know you have if you get
> segmentation faults.
>
> 3.  This one you'll run into - sometimes an API method will return
> something that SWIG doesn't know how to handle for Ruby.  For example, a
> method might return a C++ standard library strstream.  Of course, Ruby
> hasn't a clue what to do with that so a little wrapper code needs to
> generated to convert it to a string.  These are called typemaps, and
> there a bunch of them in the SWIG bindings.
>
> So, if you can port the tests and show what works and what doesn't, I
> can help out with tweaking the SWIG bindings if there are any problems.
>    And as you write the tests, I can add them into the autotest project
> for other to use as good examples in the future.
>
> Hope this helps - feel free to ping me with any questions.
>
> Charlie
>
>
>
> Shoaib Burq wrote:
> >
> > thanks
> > shoaib
> > --
> > http://nomad-labs.com
> >
> > On 6/24/06, Charlie Savage <cfis at savagexi.com> wrote:
> >> Summary
> >> -----------
> >>
> >> I've finally had a chance to look over the Ruby bindings again.  I
> >> noticed a few build issues that I wanted to run by the list, see below
> >> for more info.
> >>
> >> Overall, the Ruby bindings seem in good shape to me for OGR and OSR.
> >> There is a full set of unit tests for these modules in the gdal autotest
> >> project.
> >>
> >> However, they are not tested, and presumably do not work, for GDAL.
> >> Most likely there are a couple api calls that need a little SWIG
> >> tweaking.  Anyway, I don't have plans to do this since I only need the
> >> OGR part of the bindings.  So if someone wants to make a final push on
> >> GDAL let me know and I can point you in the right direction.
> >>
> >> Onto the build issues....
> >>
> >>
> >> Linux - Fedora Core 5, Dell Dimension machine
> >> --------------------------
> >>
> >> Compiling and installing the bindings works fine using the standard
> >> build system (./configure, make, make install).
> >>
> >> Issue #1 - However, you can't use them due to selinux errors:
> >>
> >>      Cannot restore segment prot after reloc
> >>
> >> This has to do with text relocations.  The solution turns out to be
> >> fairly simple, add -fpic or -fPIC when building shared libraries (like
> >> the Ruby bindings).
> >>
> >> Should I
> >>
> >> a) add this parameter to CFLAGS in the RubyMakefile.mk
> >>
> >> - or -
> >>
> >> b) should this be added as a global build flag?  I'd imagine all the
> >> other SWIG extensions, and the gdal shared library itself, should run
> >> into the same issue.
> >>
> >>
> >> Issue #2
> >>
> >> Ruby 1.8.4 moved its extension library from
> >> /usr/lib/site-ruby/i386-linux to /usr/lib/ruby/site-ruby/i386-linux
> >>
> >> No big deal, since I ask Ruby where the directory is on installation.
> >> However, it turns out that on a fresh ruby install the i386-linux
> >> directory doesn't exist.  So the makefile now has a check for this.
> >>
> >>
> >> Windows - VC 2005 NET
> >> --------------------------
> >> Another library issue.  With VC.NET 2005 all dlls must include an
> >> embedded manifest at resource id #2.  Yeah, I know, why????  Anyway,
> >> more information then you'd ever want to know about this is here:
> >>
> >> http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm
> >>
> >> Here's the issue.  If you build with Visual Studio, the manifest gets
> >> embedded correctly.  If you use nmake, then it doesn't and you have to
> >> add it manually use mt.exe (see link above).  Once again, this is
> >> another global issue that would affect any SWIG built extension.  It
> >> ought to also affect gdal.dll, but that seems to work for me, don't know
> >>   why.
> >>
> >>
> >> Windows - MingW
> >> --------------------------
> >> Works, no issues
> >>
> >>
> >> Os X
> >> -------
> >> Ken-ichi has reported that the bindings don't build on the Mac.
> >> Unfortunately, I can't test that since I don't have one.  Not sure what
> >> to do about that.
> >>
> >>
> >> SWIG Version
> >> ------------
> >>
> >> Last - I vaguely remember that the SWIG generated wrappers for Ruby were
> >>   after swig 1.3.28 but before 1.3.29.  I see Ari has updated Perl to
> >> 1.3.29, the latest SWIG release, so I'll make sure the Ruby bindings are
> >> at the same level.
> >>
> >> Charlie
> >>
> >>
> >>
> >> _______________________________________________
> >> Gdal-dev mailing list
> >> Gdal-dev at lists.maptools.org
> >> http://lists.maptools.org/mailman/listinfo/gdal-dev
> >>
> >>
> >>
>
>
>