[Gdal-dev] SWIG and dynamic versus static libraries

[Kevin Ruland]

Charlie,

I always thought it was unusal that the cpl methods were only in gdal. 
This was a mostly historical problem.

One of the things I thought of early on was to create a cpl module which
was all the cpl function.  This does introduce another namespace,
though.  In python, I would then trick it with "from cpl import *" in
the pythoncode header for each modules.  Ideally you'd have a mechanism
like that in ruby as well.

This might actually work to cleaning up the errorhandler confusion as well.

Kevin



Charlie Savage wrote:

> Here is another interesting one that came up testing the Ruby SWIG
> bindings for OSR.
>
> When testing a State Plane coordinate system, GDAL output a warning
> that it could not find "stateplane.csv."  It turns out this happened
> because GDAL couldn't find the GDAL directory.
>
> You can fix this by calling CPLSetConfigOption.  This API is exposed
> in the gdal module, but not in the osr module.  So the Ruby code:
>
> Gdal::Gdal.set_config_option('GDAL_DATA', dir)
> srs = Gdal::Osr::SpatialReference.new
> srs.set_state_plane(403, 1) # California III NAD83
>
> But this didn't work. The reason is because I have been compiling the
> Ruby extensions against the Windows static library and not the DLL -
> thus the GDAL module and the ORS modules each have their own memory
> area for the various CPL variables.
>
> What is the best way to handle this:
>
> 1.  Require that extensions for all languages must compile against the
> DLL on windows and shared libraries on Linux?  From what I can see,
> this is what the Python extension is doing (it ignores the DLLBUILD
> option in  gdal/nmake.opt)
>
> 2.  Expose the CPL APIs (there about ten methods exposed via SWIG
> right now) in each module (GDAL, OGR, OSR), thereby allowing either
> static or dynamic linking?
>
> Thanks,
>
> Charlie
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev