[gdal-dev] GDAL windows installers available

[Jason Roberts]

Tamas,

 

Nice job getting something out so quickly. You remind me of this Dilbert
cartoon
<http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/10000/80
00/400/18402/18402.strip.zoom.gif>  from back in the day.

 

Due to various deadlines I won't be able to look at this until Wednesday but
hope to get you some comments by that time. We should probably follow
through on Frank's request for an RFC, so the design can be reviewed and
approved according to the normal procedure.

 

I do have one request/requirement: unattended install. It would be really
great if I could include eventually include or dynamically download a copy
of the GDAL msi in my own software, and then invoke msiexec to install it
automatically. Can you make sure this is possible with your msi package?

 

BTW, when we get to the Python bindings installer, this is another reason to
build the Python bindings installer as a .msi rather than a .exe. That is
possible with Python 2.5 and later.

 

Thanks,

Jason 

 

From: gdal-dev-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Tamas Szekeres
Sent: Sunday, January 09, 2011 7:52 AM
To: gdal-dev
Subject: [gdal-dev] GDAL windows installers available

 

Folks,

Upon the inspiration on the recent conversation in this topic I've put some
efforts to automate the creation of a generic GDAL installer derived from
the distributions available at http://vbkto.dyndns.org/sdk/.

Currently the following options are available from this site to install and
use GDAL:

1. Download the .zip package extract it in some location and run
SDKShell.bat to run the commandline tools (this is the former approach)
2. Use the core msi installer to install GDAL and use the installed shortcut
to run the command line tools.  Python users should install the python
bindings installer as well.

In order to have the bindings work the location of the core files should be
added to the PATH manually (this requirement will probably be removed in the
future when the automatic loader approach is implemented at the bindings)

The core installer places an entry in the registry (currently in HKCU)
containing the install location which will allow the loader to find the
required components.

This task is not yet complete, the following issues are to be handled or
reviewed in some way.

1. Side by side installation of the multiple versions is not yet supported.
2. Must review the license agreement (currently taken from the GDAL site)
3. Must review the product name
4. Must review the installer design
5. Must review the selectable features
6. Loader approach to be implemented for the bindings
7. Versioning rules should be clarified (should synchronize the registry
entries among the versions)
8. Further fixes 


The core installer is provided as a single wix <http://wix.sourceforge.net/>
project file the build process is executed by the command line apps
(candle.exe and light.exe). I will make the whole approach public as part to
the -dev packages at http://vbkto.dyndns.org/sdk/. By using this addition
one can easily rebuild the installer after creating a customized GDAL build.

The wix project file could also be included in GDAL source tree and a new
target could be added in the gdal makefile for creating the installer (the
CRT redistributable merge modules and the dependent dlls must be available
during the build). Having the locations of the OSGeo4w files in place, this
approach could easily generate the same installer for the OSGeo4w bundle.


Any testing efforts / comments / wishes are graciously accepted.

Best regards,

Tamas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110110/2758a9b6/attachment.html