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.bar...@noaa.gov _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
