[Gdal-dev] Python next-gen bindings enabled in trunk
Chris.Barker at noaa.gov
Mon Oct 22 15:36:42 EDT 2007
Howard Butler wrote:
> - It's not apparent what we want to do for defaults on the 'make
> install' target of ./swig/python based on the discussions on the list.
> Can someone come up with a concise proposal?
I've been following this, so I'll try to write up a summary of what the
consensus seems to be where there is one, and the options where it is
not clear to me that a consensus has been reached.
Install does two things (more?)
1) install the python bindings themselves.
There are two options here:
A) don't install them -- let the user run distutils themselves.
This way they can set whatever other options they want. Maybe this
should be the case for building as well. It's the approach I've most
commonly seen with python packages based on C/C++ libs -- make to build
the lib, distutils to build/install the extension. It makes it easier to
build for multiple versions of python, build binary packages, etc.
B) Have make build and install, via distutils.
To build -- call python setup.py build.
To install -- call python setup.py install, but:
-- They get installed by distutils into site-packages
else if (prefix is set):
-- Here we have a couple options:
a) install in prefix -- I think this is poor choice
b) have a separate "python-prefix" value, and install it there (you
can pass an install path into distutils) if $prefix exists, and
$python-prefix doesn't, I suppose $python-prefix could get set to
$prefix, so it would work the same as it has been.
2) install the utilities:
It seems the consensus is that the utilities should be installed in
$prefix, rather than wherever distutils would put them, this means they
need to be installed by make, or have make or configure configure
setup.py somehow, based on $prefix -- that sounds messy to me.
A note: There was some talk recently about building a complete set of
binaries for Windows -- for a few different versions of python. Having
distutils (and/or setuptools) do all the building and installing
(including utility scripts) would make this easier to do, so maybe
having make do it isn't such a good idea.
Hmm -- I'm not sure that cleared anything up, but I think I've laid out
the options for folks to comment on.
Christopher Barker, Ph.D.
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
More information about the Gdal-dev