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

[Ari Jolma]

On 01/06/2011 01:38 PM, Tamas Szekeres wrote:
>
> 2011/1/6 Ari Jolma <ari.jolma at gmail.com <mailto:ari.jolma at 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/30d61e29/attachment.html