<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2900.3157" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Microsoft Sans Serif">
<DIV>Hi all,</DIV>
<DIV> </DIV>
<DIV>I've been watching this from the sidelines and would like to add that at St. Paul we have a use for the present behavior of installing the bindings next to GDAL.</DIV>
<DIV> </DIV>
<DIV>We have multiple versions of GDAL installed on the same machine. We do this so we can update GDAL w/o having to worry about breaking any of our (web) applications. We can test and move the applications to the new version one at a time and without disruption to our users. If the bindings are in site-* then how does one control which version of GDAL is used? With the bindings stored with GDAL, we can control which one is used by setting [DY]LD_LIBRARY_PATH and PYTHONPATH before calling the script.</DIV>
<DIV> </DIV>
<DIV>We use this method for most of our dependancies, not just GDAL, because we have been burned in the past by upgrading a product to support a new feature in one application causing another seemingly unreleated application to stop working. It took awhile to figure out and the users were not happy. I don't remember which update caused it, but I am pretty sure it wasn't GDAL so maybe we are just being over cautious.</DIV>
<DIV> </DIV>
<DIV><BR><BR>>>> On 10/15/2007 at 7:06 PM, Christopher Barker <Chris.Barker@noaa.gov> wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">William Kyngesburye wrote:<BR>> This is a different --prefix from the GDAL configure. This one is for <BR>> setup.py, and is set to the same as the GDAL configured prefix.<BR><BR>right. I'm arguing that it should NOT be set the same as the GDAL <BR>prefix. As a rule, people are not going to want to install their Python <BR>bindings in the same prefix as the GDAL lib.<BR><BR><BR>> python setup.py install --prefix=$(DESTDIR)$(prefix)<BR><BR>So that shouldn't be there. If we want to support people installing in <BR>odd places, then maybe a --python-prefix option to ./configure is in <BR>order, or just let them run setup.py themselves<BR><BR>In fact, most of the python packages I've seen that depend on other libs <BR>(PIL, wxPython), have you building the main lib with make, then running <BR>setup.py to build the python stuff -- rather than having make run that <BR>for you.<BR><BR>I may be wrong here, but I think that:<BR><BR>a) If folks have python itself installed to a non-standard location, <BR>then distutils will take care of it for them.<BR><BR>or<BR><BR>b) they really do want to install their extensions elsewhere (maybe <BR>because they don't have write permissions where python is installed). In <BR>this case, then it's probably a different location to wherever they are <BR>putting GDAL anyway -- i.e., they won't have a python packages dir <BR>inside the GDAL tree -- it would be separate, like maybe <BR>~/python/site_packages or something.<BR><BR><BR>> I have a test build online now.<BR><BR>Was it built with:<BR><BR>./configure --with-macosx-framework<BR><BR>make<BR><BR>make install<BR><BR>???<BR><BR>If so, I'll give that a try.<BR><BR>-Chris<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>Chris.Barker@noaa.gov<BR>_______________________________________________<BR>Gdal-dev mailing list<BR>Gdal-dev@lists.maptools.org<BR><A href="http://lists.maptools.org/mailman/listinfo/gdal">http://lists.maptools.org/mailman/listinfo/gdal</A>-dev<BR></DIV></BODY></HTML>