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

[Christopher Barker]

On 1/5/11 9:44 AM, Tamas Szekeres wrote:

> Supporting multiple vesions (development/stable branches/releases,
> x32/x64, multiple MSVC CRT dependencies) is quite a difficult task in a
> single installer.

yes, a Major pain. I don't know that we need a single installer, but 
there is a lot to support.

> These are the main reasons I've originally set
> up http://vbkto.dyndns.org/sdk/ to provide most of the resonable
> combinations as daily built packages.

Actually, that is a GREAT resource. At the moment, I can't remember why 
it's been difficult for me to use, but a few thoughts:

First -- I use GDAL from Python and with the command line tools, so 
that's my perspective.

1) It would be nice to have binaries for the latest release front and 
center at the main GDAL site -- having to poke around to find Tamas's 
site is not a big deal, but not always obvious.

2) A standard install location would be good. As I've messed with this 
each time, I never know where stuff should go -- maybe installers would 
help with that

3) If there is a standard install location, then "easy_install gdal" (or 
setup.py build, or...) could work for the python bindings.

Another option is to have a binary installer for the python bindings 
that includes gdal and the gdal utilities -- that would be great for 
users like me, but I don't know how common my use case is. In that case, 
you'd want to support a few recent pythons versions, the python.org 
binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).

One of the tricks here is which numpy to support, etc. numpy has been 
pretty good with binary compatibility lately (except for one mistake 
recently that was corrected)

However, I DON'T want gdal to give me  Python -- I use Python for too 
many other things for that.

4) it might be nice if the install location for the utilities got put on 
the user's PATH -- I don't know how hard that is in an installer -- 
Windows really sucks in that regard.

> I also wanted to include these files in an installer (or multiple
> installers) but at the moment I don't see the real benefit of this over
> extracting a single zip package, since these libraries don't require
> significant preparation (like regkey entries) during the deployment.

An installer would better enforce a standard install location. You could 
also have a custom DOS box with a menu entry that set up the environment 
for the command line tools (maybe only PATH?), provide an uninstaller, 
and of course, give the Windows users a nice warm and fuzzy feeling.

With regard to Python, an installer could see what Python the user has 
and install the bindings for that version. Not that I have any idea how 
to build that!

Inno Setup is a very nice free installer, by the way.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov