Phillip Pearson - web + electronics notes

Hmm ... I've changed my mind about using distutils to build htsearch. It looks like GNU Automake does actually handle Python apps, which means I won't have to mess around getting all the compiler quirk stuff that comes out of Automake working with distutils. Yay! Now to try and get my Debian install to use the right version of Automake, so it doesn't barf on the configure.in script.

Debugging notes:

• To get Python support, put AM_PATH_PYTHON(2.2) inside configure.in. Then run aclocal to get the Python stuff included in the local library cache (aclocal.m4). If you don't run aclocal, you'll get an error about AM_PATH_PYTHON not being found.
  
• It looks like you need Automake 1.7 to get the Python support ... the Debian package for 1.6 doesn't seem to include the py-compile script. (Gives the error configure.in:186: required file `./py-compile' not found).
  
• apt-get install autoconf automake1.7 will get you the right versions.
  
• To test changes to configure.in:
  
  aclocal
autoconf
automake
./configure --prefix=$HOME/htdig/cvs/inst --with-python=yes
  
• Automake seems to get confused if you set prefix but have Python installed under another prefix (it defines PYTHON_PREFIX = $(prefix)). I'm testing ht://Dig in /home/phil/htdig/cvs/inst and the resulting Makefile expects Python.h to be in /home/phil/htdig/cvs/inst/include/python2.2. The workaround is to just use --prefix=/usr, and to install the ht://Dig module in your standard Python site-packages directory later on, I guess.
  
• Automake won't let you make Makefiles that both let you build something as a library with libtool and let you build it as a normal binary (without libtool). So it looks like I can't make this coexist with the normal ht://Dig distribution ... damn. I was hoping to be able to get this included in the official version of ht://Dig, but that's looking much less likely now, unless I can convince them to build most of htsearch as a shared library, and only make little binaries for htsearch and qtest that link to that. That might be OK ...
  
• libtool calls gcc rather than g++ to generate shared libraries. This will screw up your program if you need to link to the C++ standard library:
  
  phil@icefloe:~/htdig/cvs/htdig$ python2.2
Python 2.2.1 (#1, Jul 29 2002, 23:15:49)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _htsearch
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: /home/phil/htdig/cvs/htdig/htlib/.libs/libht-3.2.0.so: undefined symbol: endl__FR7ostream
>>>
  
  Hmm - looks like libtool officially doesn't like C++. Damn. I wonder if I can export LD=g++ or something.
  
  At least the libtool manual is a funny read.
  
  If I take the last thing that libtool runs and change the gcc to g++, then cp .libs/libhtsearch.so.0.0.0 _htsearch.so and import _htsearch from python2.2 (as above), it works. Now to automate this.
  
  Aha - this may be the solution. Hmm. No, that didn't work.
  
  Here's another crack at it: don't let libtool at it at all, but compile as a program (called _htsearch.so with the link flag -shared. That's it! It worked!

So there you go. If you want to get something compiling as a Python module under Automake:

1. Put AM_PATH_PYTHON(2.2) inside configure.in
2. Put your library file (_htsearch.so) in your bin_PROGRAMS list
3. Put -shared in the LDFLAGS: _htsearch_so_LDFLAGS = -shared
4. Cross fingers, aclocal, autoconf, automake, ./configure, and build ...

Dean Goodmanson drops a reminder to go visit PyZine.com: With the additions of weblogs to Py Parlour Press's site, and it's news aggregator window of Python blogging with SpycyRoll, www.PyZine.com has become a cozy coffee-shop of a portal for the Python community.