[Gdal-dev] ng-python build

[Howard Butler]

On Oct 11, 2007, at 10:55 PM, William Kyngesburye wrote:

> As I worked on some OSX framework build issues, I noticed a couple  
> odd ng-python build items.
>
> - After configuring to build ng-python, make doesn't build *any*  
> python bindings.  It looks like the makefile default target doesn't  
> refer to the swig-target, just the old py-target.  BUT, install  
> does - the install-actions target runs a make install in the swig  
> dir, which ends up building ng-python.

I think this was because of libtool and linking trouble with -lgdal  
as it is built in the tree.  I think Kevin was the one who originally  
did the target for the ng bindings.  I have always built them by  
hand, but I am expecting to deal with these issues before the 1.5  
release.  Can you please file a ticket for this one and pick the  
PythonBindings as the component?

>
> - ng-python installs in $prefix.  This ends up being installed  
> where-ever GDAL is installed, in the subdir thereof specified in  
> the python distutils (something like lib/python2.5/site-packages).   
> Is this intentional?  Shouldn't it be left completely up to  
> distutils so it gets installed in the default python site-packages  
> dir?
>

This is what the old bindings did as well, which is why it currently  
does this by default.  However, with the ng bindings, the situation  
is more inconsistent than that:

-- If setuptools is installed, use that to build and do "install -- 
root / --single-version-externally-managed".  By default this means  
an egg file gets put in your Python path (typically site-packages)
-- If setuptools is not installed, install in --prefix as before.

What makes the most sense for installation and building of the Python  
bindings?  There are so many different ways to skin this cat now that  
we are using setuptools/distutils by default.  I'd like everyone to  
chime in who has an opinion.  I think putting stuff in --prefix by  
default is confusing for most folks, but installing stuff in the root  
of your Python install isn't too friendly either...

As things are currently defined, setuptools is used *by default* if  
configure or setup.py determines that it is available. Regular  
distutils is then used if setuptools isn't available.  I would hate  
to *require* setuptools, but it would simplify troubleshooting  
things.  Our default install: targets basically install the bindings  
the same way regardless of whether or not setuptools is available,  
and the major benefit is if you want to hand build things, you have a  
lot more options.

My opinions:
-- I really like setuptools for the 'develop' target and even for  
eggs now that we use them on the osx buildbot slave (everything is  
self-contained and it doesn't end up polluting the rest of my machine  
with new and possibly broken bindings and we don't have to do  
sys.path hacking). I can see providing the ng bindings as eggs for  
windows, for example.
-- './configure --with-python;make;make install' needs to do the most  
straightforward thing for Python users (we need to define what that  
is, and it is my opinion that installing in --prefix *isn't* it).   
Someone wanting to do fancier stuff should have to run setup.py  
themselves.

Howard

PS.  This discussion reminded me of the best feature of the ng  
bindings in the upcoming 1.5 release... docs!  I figured out a way to  
incorporate the doxygen docs into docstrings as part of the swig  
generation.  pydoc away... :)