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

[nia <nia%NetBSD.org@localhost>]

On Mon, Jun 21, 2021 at 08:51:58PM +0200, Dr. Thomas Orgis wrote:
> 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.

This should be fixed.

> 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

Please understand I am trying to reduce friction by following other
package managers.

https://repology.org/project/fftw/versions

> 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?

You're asking that we break the package for users of pkgsrc gcc...

> 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 …

I realize you don't care about providing working binary packages
to end-users, but it's very important for my primary mission of
making pkgsrc useful for NetBSD users. That means not introducing
arbitrary build failures.