ghisvail/pyNFFT — pull request #27 by cmarquardt (2014-05-20 22:00:38+00:00)
Title: Portability issues

Hi,

first, many thanks for providing a python interface to nfft!

I'm trying to use it on Mac OS-X (Mavericks) and ran into two portability issues:

#### 1. Hardcoded compiler options

At some point on your solver-fix-props branch, you added hardcoded compiler options for gcc to `setup.py`. This isn't portable; for example, clang on MacOS-X doesn't know about `-malign-double` (which only makes sense on 32-bit platforms anyway), and therefore the compilation of the module fails. For Intel compilers, `-ffast-math` doesn't exist (it's `-fast`). Oh, and `-O3` should be triggered by `-ffast-math`.

I think it would be a more portable approach to rely on Python's build system to specify meaningful compiler options. As an alternative, users could use `CFLAGS` etc. environment variables to add compiler options when building a module if they really want to. Unfortunately, and as far as I know, `distutils` does not provide a good and standardised way to specify things like compiler options during compile time. A setup.cfg based solution could also be envisaged, as I did for the second issue below, but that's not a "standard" solution either.

#### 2. Threaded libraries

In issue #16 of pyNFFT's issue queue, installing on Windows failed at some point because no threaded version of the `fftw` library was available for the user. I don't know if that's common on Windows, but it can certainly happen. Similarly, on Mac OS-X, the clang compiler coming with Apple's XCode development environment does not support openmp, so `nfft` can't even be built with threading enabled. One possible solution would be to install a more recent version of `gcc` - but is it really worth the effort to install a second compiler suite just for installing a python module, especially as `nfft` can be build perfectly without threading support? Overall, I think, it would help portability a lot if the build tools for pyNFFT would allow a choice if the threaded versions of the libraries should be used or not.

As a possible initial proposal on how to implement this, I have added options to the `setup.cfg` file which allow to switch the use of threaded libraries for fftw and nfft individually. It's also possible to set environment variables, but the setup.cfg options will override the environment variable settings if they are also present. I've also updated the existing `setup.cfg` file and provide a template variant which includes some explaining comments. In order to make the environment variables work, I would not provide a `setup.cfg` in a release tar ball, but expect users to manually copy the `setup.cfg.template` if they want to use it. The implementation is based on a similar approach in the netcdf4 module for python https://github.com/Unidata/netcdf4-python). It's not perfect, and one could try to implement some automatic detection if the threaded libraries exist or not. Then again, it's simple, and it's really a shortcoming of python's `distutils` that such things can't be set via command line options during the the build.

Thanks for considering this pull request...