2011/1/6 Ari Jolma <[email protected]> > > 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
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
