Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

Tamas Szekeres szekerest at gmail.com
Thu Jan 6 08:25:23 EST 2011


2011/1/6 Ari Jolma <ari.jolma at gmail.com>

>
> By the age I meant that the SDK packages are old releases (from 1310 to
> 1600 and not trunk for example - do I understand the release names
> correctly?)
>
>
>
Ari,

Those numbers are MSVC compiler numbers (according to
http://trac.osgeo.org/gdal/browser/trunk/gdal/nmake.opt) not gdal version
numbers.

CPAN has only sources, thus cpan application which is the standard to
> download and install perl modules expects you to have a compiler.
>
> ActivePerl (in fact ActiveState, the company) maintains a repository of
> perl modules in binary versions, from where they can be simply downloaded
> and installed with another program. ActivePerl has tools for developing
> those binary packages. That's very similar to what Python has. I think
> ActiveState maintains its repository by itself - so if I just make the CPAN
> module intelligent enough it may end up there eventually. I think my
> Geo::Shapelib module was/is there.
>
> I think it would not make sense to include GDAL into such a binary perl
> module package. Thus GDAL would need to be separately installable - the
> module installer could probably be made to offer install it for the user if
> it existed somewhere.
>
>
This is also the case with python and the other bindings: the gdal dll-s and
dependencies should also be installed somewhere. Assuming we install the
gdal-perl modules in a standard location (not sure where it is), do we have
a common mechanism in the perl runtime to find the dependent dlls without
having to violate system wide settings (like the PATH environment variable)?

Best regards,

Tamas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/4ffc89d1/attachment-0001.html


More information about the gdal-dev mailing list