math/fftw-long / math/fftw-quad broken on Linux as it pulls in math/libquadmath, which is superfluous and broken on Linux

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

Hi,

in my freeze testing, I noticed that the fftw-long option is gone an
been rolled into a standalone package. I missed this change to my
revamped fftw before the freeze. Right after I merged fftwf into fftw
since single and double precision are sensible to always have present.
The reasoning for the recent dissection is this:

----------------------------
revision 1.1
date: 2021-05-16 12:14:09 +0200;  author: nia;  state: Exp;  commitid: 762XfOm0wwYnhmTC;
split fftw package into -long and -quad precision variants

the package previously used PKG_OPTIONS for this, but PKG_OPTIONS
are harmful in the case that they effect the resulting ABI of
library packages. this way, things that actually need fftwl and fftwq
can depend on these sub-packages.

this also fixes fftwq on NetBSD by making it pull in libquadmath.
another thing about PKG_OPTIONS for library components is that
they mean certain components don't get tested...
=============================================================================

The problem I now have is that math/libquadmath is a hard dependency of
fftw-long and fftw-quad and it is broken for me on Linux for two reasons

1. It has PLIST failures as it installs libquadmath.la into
   ${PREFIX}/lib64 or ${PREFIX/libx32 (wtf?!) for my systems.

2. It should not be there at all, as libquadmath is provided by my host
   gcc.

Because of 2 I am reluctant to investigate a fixup of the build of
libquadmath. I don't want two of those.

And also … I don't quite get the PKG_OPTIONS argument as long as we got
this:

${PLIST.omp}lib/libfftw3q_omp.la
${PLIST.pthreads}lib/libfftw3q_threads.la
${PLIST.mpi}lib/libfftw3f_mpi.la
${PLIST.omp}lib/libfftw3f_omp.la
${PLIST.pthreads}lib/libfftw3f_threads.la
.
Being sincere would then mean to add

math/fftw-mpi
math/fftw-omp
math/fftw-threads
math/fftwl-mpi
math/fftwl-omp
math/fftwl-threads
math/fftwq-mpi
math/fftwq-omp
math/fftwq-threads

and not just math/fftw-long (or the more canonical math/fftwl) and
math/fftw-quad (fftwq). Also, the presence of

${PLIST.mpi}include/fftw3l-mpi.f03
include/fftw3l.f03
include/fftw3q.f03

in fftw/PLIST might be questionable.

While the splits are somewhat philosophical in nature, the breakage due
to unwanted libquadmath is something very real.

It was added for NetBSD. So shouldn't the dependency be guarded by a
platform check?

About the PKG_OPTIONS affecting ABI: There is no way in pkgsrc to
depend on a certain option in a library besides writing code that
explicitly looks at the PKG_BUILD_OPTIONS.library and errors out if not
set? It would be awfully nice if you could depend on fftw built with a
certain option. In general, this can mean the same library files, but
just some differing symbols in them …

The current state is a strange mix, anyway. The quad/long variants are
rather special. I envisioned the options for users that want to build
some custom software on top. I am not aware of something standard being
packaged in pkgsrc that actually wants more than double precision. You
should worry more about the parallel variants, I guess. So … full split
or back into one? Do you have actually a package that does depend on
long/quad FFTW?

And if we do keep split … fftwl and fftwq really are better names for
the packages, as the libraries are named that way. Too late to change
that now?


Alrighty then,

Thomas

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