<span dir="ltr">Chris,<br><br>Good points below, but having the compiled gdal binaries (and the binaries of the dependent libraries) in hand, which is the right way to install those files on Windows? (Assuming we don't provide python.exe and the related files in the package)? I mean which install actions should be done in detail?<br>
<br>Best regards,<br><br>Tamas<br></span><br><br><br><div class="gmail_quote">2011/1/5 Christopher Barker <span dir="ltr"><<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It may well be that GDAL has too many different use cases to even have a "standard" install, but...<div class="im"><br>
<br>
On 1/5/11 1:37 PM, Tamas Szekeres wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2011/1/5 Christopher Barker <<a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a><br>
1) It would be nice to have binaries for the latest release front<br>
and center at the main GDAL site -- having to poke around to find<br>
Tamas's site is not a big deal, but not always obvious.<br>
</blockquote>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
With regards to the comment above, while I'm not sure about the<br>
objectives but I don't think the GDAL site would intend to be a hosting<br>
provider of various binary packages,<br>
</blockquote>
<br></div>
Well, many (most?) open source packages have "official" binaries hosted on its site. It's pretty common to go to a project's site and expect to find a way to download binaries right then and there.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2) A standard install location would be good. As I've messed with<br>
this each time, I never know where stuff should go -- maybe<br>
installers would help with that<br>
<br>
This doesn't seem to be decisive requirement to me.<br>
</blockquote>
<br></div>
It's not a strong requirement, but standard defaults do make things easier for everyone.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Or some other folks may prefer installing these files<br>
along with their applications or keep such files in separate - project<br>
specific - directories.<br>
</blockquote>
<br></div>
Well, users should certainly be able to do something custom if they want. This is all about use-cases -- if you are building a custom app linked against GDAL, then you probably want to control where you put things.<br>
<br>
However, if you are interested in the command line tools, and using GDAL via Python or Perl or ??, then it makes it easier to have a standard location.<div class="im"><br>
<br>
> Another issue of an installer may be due to a single product key<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
along with the setup which would prevent from installing multiple<br>
versions side by side in the same environment.<br>
</blockquote>
<br></div>
Surely there are ways to accommodate that? though "dll hell" is in the lexicon for a reason!<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3) If there is a standard install location, then "easy_install gdal"<br>
(or setup.py build, or...) could work for the python bindings.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I admit I don't have enough knowledge about the 'magic' tricks related<br>
to python-ish way installing applications.<br>
</blockquote>
<br></div>
That's the thing -- there is no magic here. If you are building a python extension, you need to tell the build system where its dependencies lie. If you are installing a pre-built python extension, then the dependencies need to be in a known place (or maybe on the right PATHS -- Windows is pretty ugly this way). Which is why a "standard" install location would be a good idea.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I might also consider<br>
running a custom application with gdal not necessarily be the<br>
responsibility of a GDAL package.<br>
</blockquote>
<br></div>
well, that depends on whether you consider Python bindings a "custom application". In any case, I think it helps third party packages to have standard default install locations.<br>
<br>
Oh for *nix -- this would be easier if we just could just put stuff in /usr/local/...<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
You might also want to install python<br>
from a separate installer (either ActivePython, <a href="http://python.org" target="_blank">python.org</a><br></div>
<<a href="http://python.org" target="_blank">http://python.org</a>> whatever)<br>
</blockquote>
<br>
True -- but it is very much a standard for third party packages to provide binaries for the <a href="http://python.org" target="_blank">python.org</a> python build. Again, I'm not suggesting that folks should be prevented (or even discouraged) from doing various sorts of custom installs, just that there should be defaults, so that it's clear an easy for a newbie to know what to to to get things to "just work".<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
Another option is to have a binary installer for the python bindings<br>
that includes gdal and the gdal utilities -- that would be great for<br>
users like me, but I don't know how common my use case is. In that<br>
case, you'd want to support a few recent pythons versions, the<br></div>
<a href="http://python.org" target="_blank">python.org</a> <<a href="http://python.org" target="_blank">http://python.org</a>> binaries: 2.6, 2.7, 3.1 (maybe 2.5 too).<div class="im"><br>
<br>
I don't know much about this either. This may however be doable for<br>
those guys who know the Python packaging approach well enough.<br>
</div></blockquote>
<br>
It's not that hard (at lest once GDAL is built), but it is work.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I don't<br>
think eiter of the packages referred at<br>
<a href="http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries" target="_blank">http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries</a> would support<br>
this feature though.<br>
</blockquote>
<br></div>
Agreed -- that's my point!<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
One of the tricks here is which numpy to support, etc. numpy has<br>
been pretty good with binary compatibility lately (except for one<br>
mistake recently that was corrected)<br>
<br>
<br>
Not sure how this be related to a GDAL binary distribution, as far as I<br>
remember numpy can be installed to the Python deployment directly.<br>
</blockquote>
<br></div>
yes, but the Python bindings are built against a particular numpy. That's OK for version so numpy that are binary compatible, but it potentially fragile. Note that with the new extended buffer interface, it should be possible to build GDAL with full numpy support, but not have to compile against numpy. But I think that's only good for 2.7 and 3.*<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
However, I DON'T want gdal to give me Python -- I use Python for<br>
too many other things for that.<br>
<br>
Yes, adding more runtime environments to a simple GDAL package makes it<br>
more heavy weighted.<br>
</blockquote>
<br></div>
right -- I think we're talking about lightweight, GDAL only packages here.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
in many cases it's more reasonable to let the<br>
application (using the GDAL binaries) decide how to make a proper<br>
installer to run their application smoothly.<br>
</blockquote>
<br></div>
Hmm -- that's the trick -- are the Python (and Perl, and...) bindings an "application (using the GDAL binaries)", or are they part of GDAL? In many cases, the python bindings are a completely separate project from the library they bind, so it's a clear distinction, but not in this case.<br>
<br>
This makes me think, though -- maybe I should think about this differently -- I'm trying to get the GDAL command line tools, and the Python bindings. Maybe I should simply consider those as separate issues altogether -- they don't need to share the same binaries. In that case, maybe the python bindings should be statically linked, or deliver the dlls with the bindings, and be available as an entirely stand-alone installer.<br>
<br>
Indeed, having said that, I'm looking around and see that someone is doing that:<br>
<br>
<a href="http://www.lfd.uci.edu/%7Egohlke/pythonlibs/" target="_blank">http://www.lfd.uci.edu/~gohlke/pythonlibs/</a><br>
<br>
very nice -- I'll have to give those a test.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4) it might be nice if the install location for the utilities got<br>
put on the user's PATH -- I don't know how hard that is in an<br>
installer -- Windows really sucks in that regard.<br>
<br>
I don't think it would be beneficial in most cases. This could easily<br>
break other applications (using the dll-s with the same names) to fail<br>
unexpectedly.<br>
</blockquote>
<br></div>
I was thinking the executable utilities, not the dlls, but Windows does conflate those PATHs, doesn't it? (sigh)<br>
<br>
Anyway, next time I update my Windows system (which I'll need to do soon), I'll think about these issues some more.<br>
<br>
A couple notes on:<div class="im"><br>
<br>
<a href="http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries" target="_blank">http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries</a><br>
<br></div>
Looking again at that page, I'm reminded why this has seemed painful. Under the Windows section:<br>
<br>
"""<br>
Minimalist windows executables are available at:<br>
<br>
<a href="http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip" target="_blank">http://download.osgeo.org/gdal/win32/1.6/gdalwin32exe160.zip</a><br>
"""<br>
<br>
these are out of date -- if they are going to exist, they really should be updated. They are hosted by osgeo, and thus look "official".<br>
<br>
"""<br>
Other plugins will be added in the same location (such as Oracle/OCI):<br>
<br>
<a href="http://download.osgeo.org/gdal/win32/" target="_blank">http://download.osgeo.org/gdal/win32/</a><br>
"""<br>
<br>
How well maintained is this set?<br>
<br>
"""<br>
A more featureful set of windows binaries, including python, proj and c# support is available as part of the FWTools package.<br>
"""<br>
<br>
no longer kept up to date, either.<br>
<br>
"""<br>
Windows binaries built in MinGW are available at:<br>
<br>
<a href="http://map.hut.fi/files/Geoinformatica/win32/" target="_blank">http://map.hut.fi/files/Geoinformatica/win32/</a><br>
<br>
The Geoinformatica-yy-mm-dd.zip contains GDAL (usually a development version), Perl-GDAL, Perl, and many other things.<br>
"""<br>
<br>
good for MinGW users, I suppose -- I remember them not working for me, tough I can't recall how or why not. They also suffer from perhaps trying to be too much (though if it all worked, I wouldn't care, I have a fast network and large hard drive)<br>
<br>
<br>
"""<br>
Tamas Szekeres maintains a complete set of Win32 and Win64 binary packages (compiled with VC2003/VC2005/VC2008) available at the following location.<div class="im"><br>
<br>
<a href="http://vbkto.dyndns.org/sdk/" target="_blank">http://vbkto.dyndns.org/sdk/</a><br>
"""<br>
<br></div>
These are fabulous -- maybe they should be first on the list? Though there is a LOT there -- you need to know what you are looking for.<br>
<br>
"""<br>
OSGeo4W is a binary distribution of a broad set of open source geospatial software for Win32 environments (Windows XP, Vista, etc). OSGeo4W includes GDAL/OGR, GRASS, MapServer?, OpenEV, uDig, as well as many other packages (about 70 as of summer 2008).<br>
"""<br>
<br>
I think for folks that are primarily FOSS4G folks, this is great. A bit of a mess if you just want GDAL though.<div><div></div><div class="h5"><br>
<br>
-Chris<br>
<br>
<br>
<br>
-- <br>
Christopher Barker, Ph.D.<br>
Oceanographer<br>
<br>
Emergency Response Division<br>
NOAA/NOS/OR&R (206) 526-6959 voice<br>
7600 Sand Point Way NE (206) 526-6329 fax<br>
Seattle, WA 98115 (206) 526-6317 main reception<br>
<br>
<a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>