[Gdal-dev] ng-python build

[Jim Klassen]

Hi all,
 
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.
 
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.
 
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.
 


>>> On 10/15/2007 at 7:06 PM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:
William Kyngesburye wrote:
> This is a different --prefix from the GDAL configure.  This one is
for 
> setup.py, and is set to the same as the GDAL configured prefix.

right. I'm arguing that it should NOT be set the same as the GDAL 
prefix. As a rule, people are not going to want to install their Python

bindings in the same prefix as the GDAL lib.


> python setup.py install --prefix=$(DESTDIR)$(prefix)

So that shouldn't be there. If we want to support people installing in

odd places, then maybe a --python-prefix option to ./configure is in 
order, or just let them run setup.py themselves

In fact, most of the python packages I've seen that depend on other
libs 
(PIL, wxPython), have you building the main lib with make, then running

setup.py to build the python stuff -- rather than having make run that

for you.

I may be wrong here, but I think that:

a) If folks have python itself installed to a non-standard location, 
then distutils will take care of it for them.

or

b) they really do want to install their extensions elsewhere (maybe 
because they don't have write permissions where python is installed).
In 
this case, then it's probably a different location to wherever they are

putting GDAL anyway -- i.e., they won't have a python packages dir 
inside the GDAL tree -- it would be separate, like maybe 
~/python/site_packages or something.


> I have a test build online now.

Was it built with:

./configure --with-macosx-framework

make

make install

???

If so, I'll give that a try.

-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 
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org 
http://lists.maptools.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20071016/b8b9d2fe/attachment.html