On 01/06/2011 01:38 PM, Tamas Szekeres wrote:
2011/1/6 Ari Jolma <ari.jo...@gmail.com <mailto:ari.jo...@gmail.com>>
GDAL is available but again typically as MS compiler builds -
which should not be a problem in theory because the bindings use
it through the C API. I've tried to use those a couple of times
without luck (compiling the bindings in MinGW was the problem).
Maybe I should try again using binaries from Tamas' site.
I agree that there could be a one main site for GDAL Windows
binaries (something like
http://www.gtk.org/download-windows.html). Tamas' site looks good
but I'd like to have dev packages also (the SDK packages there
look old) - just the header files should be enough.
Ari,
The SDK packages from http://vbkto.dyndns.org/sdk/ are exactly the
same which have been used to compile the daily builds, so it should be
up to date. The only thing may have to be done is to download the
required version of the gdal sources in the root folder, because not
all of the versions included in the package in order to keep the size
as small as possible.
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?)
BTW: What is the desired practice to install the gdal files + bindings
along with a pre-installed perl runtime on Windows? Something like we
have been discussing for python in this thread, do we have some
desired install locations, environment settings or packaging conventions?
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.
In short /me thinks the requirements are: 1) /me develop the perl
bindings configure & make procedure better 2) we make GDAL-dev.msi
available at an URL.
Ari
Best regards,
Tamas
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
