math/fftw and math/fftwf split …

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Hi,

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 

lib/libfftw3.la
${PLIST.pthreads}lib/libfftw3_threads.la
include/fftw3.f
include/fftw3.f03
include/fftw3.h
include/fftw3l.f03
include/fftw3q.f03

(note: no lib/libfftw3l.la and no lib/libfftw3q.la to match the fortran
files)

and math/fftwf installs

lib/libfftw3f.la
${PLIST.pthreads}lib/libfftw3f_threads.la

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

Now, math/fftwf _also_ does this:

include "../../math/fftw/buildlink3.mk"


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
    double)
      OPTS="$COMMON_OPTS $DOUBLE_OPTS" &&
      cd "$SOURCE_DIRECTORY/double"
    ;;
    single)
      OPTS="$COMMON_OPTS $SINGLE_OPTS --enable-float" &&
      cd "$SOURCE_DIRECTORY/$p"
    ;;
    longdouble)
      OPTS="$COMMON_OPTS --enable-long-double" &&
      cd "$SOURCE_DIRECTORY/$p"
    ;;
  esac &&
  ./configure $OPTS && make && make install
done

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

Was that the preferred idea that just was not implemented?


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

bin/fftw-wisdom-to-conf
include/fftw.h
info/fftw3.info*

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.

Thoughts?


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg