tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

math/fftw and math/fftwf split …


I am in the process of merging my patch that adds the MPI and OpenMP
options to math/fftw, I stumbled upon the peculiar split between
math/fftw and math/fftwf in CVS.

So far, math/fftw installs 


(note: no lib/ and no lib/ to match the fortran

and math/fftwf installs


There seems to be no Fortran interface for the single precision variant.

Now, math/fftwf _also_ does this:

include "../../math/fftw/"

So installing math/fftwf pulls in the double-precision fftw anyway. You
cannot just install the single precision one, which is usually needed
as a dependency for audio software.

What's the point of separating the moderate file count and size of
fftwf at all? What is the plan? I see two sensible options:

1. math/fftw always installs single precision and probably double
precision, long double and even quad as options. Do not install the l
and q Fortran interfaces if not building the lib for that.

2. math/fftw, math/fftwf, math/fftwl, math/fftwq are created to each
install the specific library for the selected precision.

For another packaging system, I made the fftw package support options
for the precisions as well as MPI/OpenMP (what I wanted to add right
now to pkgsrc). It does separate builds, actually:

# Build each precision by itself.
for p in $FFTW_PRECISION; do
  case "$p" in
      cd "$SOURCE_DIRECTORY/double"
      OPTS="$COMMON_OPTS $SINGLE_OPTS --enable-float" &&
      cd "$SOURCE_DIRECTORY/$p"
      OPTS="$COMMON_OPTS --enable-long-double" &&
      cd "$SOURCE_DIRECTORY/$p"
  esac &&
  ./configure $OPTS && make && make install

I guess this would easiest translate to separate packages with a
Makefile.common and a common (for Fortran, MPI, …).

Was that the preferred idea that just was not implemented?

Regarding the split package variant, one needs to decide who installs


I guess this is a reason to always pull in the double precision variant
to be able rely on those files without conflict (fftw.h is common to
all variants). But then, building all libs in one go might be sensible.

Of course I can just add the MPI and OpenMP options to the packages as
they are now, but it feels a bit incomplete. We should decide whether
to build the precisions together in math/fftw and drop math/fftwf or
reduce it to an empty shell, or to add math/fftwl and math/fftwq.


Alrighty then,


Dr. Thomas Orgis
HPC @ Universität Hamburg

Home | Main Index | Thread Index | Old Index