RE: SWIG and autotools - some solutions (corrected further)

ARGH! Correcting my corrections (use of "dir" in pythonSitePackages). At
least the last one made it into the archives this time. Sorry again for
the traffic.

============================
(Reposted with corrections, and original didn't make it into the
archives for some reason).

============================
This seems to be a problem for a number of SWIG'ers, so I'll risk the
off-topic automake discussion and describe a couple automake features
I've used that some of you may find useful. ;)

============================
PROBLEM (1):
SWIG generates shared libraries having a name with a leading underscore,
but libtool expects libraries to start with "lib".

SOLUTION: 
Specify the "-module" option to LDFLAGS. For example, if you are
building a module called gumby:

lib_LTLIBRARIES = _gumby.la
_gumby_la_LDFLAGS = -module

This will, amongst other things, prevent automake/libtool from
prepending "lib" to the library name.

============================
PROBLEM (2):
Python doesn't find my SWIG modules when I try to import them.

CAUSE:
Python doesn't know to look for the the SWIG-generated .py file in the
directory you have built it in.

SOLUTION:
There are a few different ways to solve this, depending on what your
final installation requirements are. Two solutions are given below (we
will assume you are building a module called "gumby"):

SOLUTION (A): Not installing anywhere (leaving files in build tree).
You need to set your PYTHONPATH so that python can find the .py file
swig generates, plus set your LD_LIBRARY_PATH so that the system can
find the .so library itself. If they are in the same directory, you may
not neet to bother setting LD_LIBRARY_PATH (haven't been able to confirm
this definitively yet). As mentioned in a recent post, automake puts the
libraries in a .libs subdirectory, but the .py file will not be. This
complicates setting PYTHONPATH, but can be alleviated somewhat by
creating a symbolic link to the .libs/_gumby.so file.

SOLUTION (B): Installing into system's python site packages area.
This solution is particularly relevent to those packaging RPM's or who
have root access and don't mind installing things into system areas
(which I don't necessarily support!). It also happens to be a much
easier solution. ;)
Automake allows you to define your own installation directories, not
just force you to use /usr/local/bin, /usr/local/lib and so on. If you
know where your python site-packages area is, you can specify it as the
install location for the library and the .py script swig generates. For
example, on Red Hat 9.0 the python site packages are in
/usr/lib/python2.2/site-packages. Other systems may have python
installed in /usr/local, so their site packages might be in
/usr/local/python2.2/site-packages (but I haven't checked this). Since
automake already defines a $(prefix) to take care of the /usr or
/usr/local bit, we end up with the following neat solution:

pythonSitePackagesdir = $(prefix)/python2.2/site-packages
pythonSitePackages_LTLIBRARIES = _gumby.la
pythonSitePackages_SCRIPTS = gumby_wrap.py
_gumby_la_SOURCES = ....

No need for install-exec hooks or any other special stuff. Just do a
"make install" and automake simply installs things where they need to go
automatically (assuming you have write access to relevent areas). Note
that you could install the shared library and the swig-generated python
script to different areas if you wanted. This could be used to put the
python file somwhere already in the PYTHONPATH (possibly even an area
not requiring root access for writing), then put the library in a
different location already in LD_LIBRARY_PATH or somewhere ld already
looks for libraries.

============================

As an aside, automake can also be used to build and install packages
with sub-modules built by swig. It is fairly easy, but probably getting
too off-swig-topic. If anyone is interested, email me privately. I'll
post it if there is sufficient interest (and when I have more time!).

Cheers.


On Fri, 2004-05-07 at 06:12, Drummonds, Scott B wrote:
> From: swig-admin@xxxxxxxxxxxxxxx [mailto:swig-admin@xxxxxxxxxxxxxxx] On
> Behalf Of Pereira, Ricardo Scachetti
> > Part of the problem is that Python is expecting something called 
> > _modulename.so. But I can only compile a .la library using autotools.
> > So, how do I solve this problem? 
> 
> Ricardo,
> 
> Here is what I am doing in my setup, which sounds identical to yours:
> 
> 'make install' will put your target library (_ompython.la) in
> ${prefix}/lib.  You can then add a softlink of the Python-expected name
> to this same directory by adding an install hook:
> 
> <quote>
> install-exec-hook:
>       ln -fs ${prefix}/lib/_ompython.so.0.0.0
> ${prefix}/lib/whatevermodule.so
> </quote>
> 
> With ${prefix}/lib in your PYTHONPATH, you'll be able to execut 'import
> whatever'.
> 
> Note that if you want to work from your build directory (and not the
> install directory) the shared libraries are put in the subdirectory
> ".libs" from the directory in which the source resides.  You can
> similarly add a target to these libraries that is updated every time you
> type 'make':
> 
> <quote>
>       ln -fs .libs/_ompython.so.0.0.0 whatevermodule.so
> </quote>
> 
> Check the Automake documentation to find out to which hook you should
> add this line.
> 
> Scott
> _______________________________________________
> Swig maillist  -  Swig@xxxxxxxxxxxxxxx
> http://mailman.cs.uchicago.edu/mailman/listinfo/swig
-- 
Craig Scott, CSIRO (CMIS)
Ph:  +613 9545 8096

Computers are easy to reboot. Attitudes are much harder.

_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig