[Gdal-dev] Python next-gen bindings enabled in trunk

[Vincent Schut]

Christopher Barker wrote:
> 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:
>
>  If (default):
>   -- 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.
>
> -Chris
My preferences:

make: runs setup.py build
make install:
    - runs setup.py install for bindings
    - separately installs scripts in prefix, alongside the other gdal
utilities.

Cheers,
Vincent.