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

[Howard Butler]

All,

Today I have enabled the next-gen bindings in trunk, and they are  
built by default when using the --with-python target.  More testing  
is needed/requested, so please file tickets or let me know in IRC of  
any issues that arise.  Here are the particulars:
1) All references to the old bindings in ./pymod are called old-gen  
python in configure and makefiles
2) Specific references to SWIG xxx bindings are now just called xxx  
bindings (perl, python, java, etc)
3) 'make' executes the 'build' target in swig/python when --with- 
python is enabled
4) 'make install' installs a python egg in the system location if  
setuptools is available and an otherwise regular python package in  
the system location if just distutils is used
5) enabling the old-gen bindings now requires passing --with-ogpython  
to configure
6) enabling the old-gen bindings disables the next-gen bindings
7) Only libtool builds have been tested thus far
8) The references to scripts in pymod need to be sync'd with those in  
swig/python/scripts ('make install' in ./pymod will eventually use  
the same scripts in ./swig/python/scripts)
9) --with-pymodddir only has an effect when --with-ogpython is enabled.

Outstanding issues:
  - 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?
  - Because we're using distutils, currently the CFLAGS and CPPFLAGS  
of Python are used, and GDAL's CFLAGS/CPPFLAGS are not injected.   
This needs to be resolved.
  - The windows makefiles have not been updated yet.
  - Should we require setuptools, or should we attempt to support  
setuptools and distutils?

Test away (please),

Howard