tags:

views:

48

answers:

2

I'm looking into releasing a python package which includes an existing fortran or C program. The fortran/C program is compiled by running

./configure
make

The python code calls the resulting binary through subprocess calls (i.e. the code is not really wrapped as such). What I would like is that when the user types

python setup.py install

the fortran/C program is first compiled using the ./configure and make commands, then I want the python module to be installed, and the binary to be installed in the python bin/ directory alongside executables that are usually installed via the scripts= option in distutils.core.setup.

First, are there any problems with doing this? And if not, what is the best way to do it via setup.py? Are there existing functions to automate the ./configure and make, since this is pretty standard? Or should I just use os.system calls? And either way, where should those commands go in setup.py? Then should I have make output the binary to e.g. scripts/ and then have scripts=['scripts/mybinary'] in the setup() function?

+1  A: 

Don't make this too complex.

Just provide them as separate items with a README that says -- basically -- what you said in the question.

  1. Build the Fortran/C with ./configure; make; make install.

  2. Setup Python with python setup.py install.

It doesn't appear to be rocket science. Trying to over-simplify the installation means that you must account for every OS vagary and oddness.

It's easier to trust the users to do "standard" installations so that the Fortran/C is on the system PATH, and your Python script should be configured to find them on the system PATH.

People who want to use your software are then free to reconfigure it to their own unique needs. They will anyway. Don't overpackage and force them to fight against you to reconfigure things.

S.Lott
A: 

consider writing a python C extension as a wrapper for your C code, and a f2py extension as a wrapper for your fortran code. Then you can just use them in your python code as fast calls instead of using subprocess.

nosklo