pfft
pfft copied to clipboard
mpip
use embeded fftw3 as a subpackage
This hugely simplifies the building process of pfft. Since the new planners are unlikely to be included in next release of FFTW in any short term, it makes sense to just ship in a release the patched version of FFTW that is known to work with PFFT.
This currently requires --enable-mpi on the configure scripts. threading support is untested.
Thank you for the patch. I will have a look on it. However, it might be a bit more difficult, since PFFT is also a submodule of PNFFT and ScaFaCoS. ScaFaCoS comes with its own FFTW clone -- but there we must prefix all FFTW functions with fcs_fftw_ in order to avoid linking errors.
I have to think of a nice approach that allows PFFT to come with its own FFTW and PNFFT to come with its own FFTW and PFFT. The solution must be compatible with ScaFaCoS, that comes with its own FFTW, PFFT and PNFFT. In addition, it should be possible that the user provides its own versions of the dependencies via CFLAGS and LDFLAGS.
May I ask why PFFT has a FFTW, PNFFT has another FFTW, and ScaFaCoS has a third FFTW? What is the difference between these FFTWs?
FYI, a requirement on a patched version of FFTW would seriously hinder any attempts to package these pieces of software for Linux.
on the PFFT side, an alternative is to give FFTW the ability to accept additional planners. That may be easier to get accepted than, supplying with new planners that FFTW upstream doesn't make use of.
What customization to FFTW does PNFFT and ScaFaCoS require?