Created attachment 196873 [details]
One port that I work on requires fftw3 with OPENMP=on and OPENMPI=on.
Ideally, OPENMP and OPENMPI should be sub-packages, but we don't have sub-packages yet.
For the time being, I suggest to make them default. Once sub-package functionality arrives, they could be converted to sub-packages.
Unfortunately, that would burden all consumers of fftw3 with gcc and openmpi including heavily used consumers like pulseaudio and ImageMagick. I think that is just too much overhead for the sake of one port.
I'm not sure what the consequences would be on tier 2 archs either. Work is being done to improve OPENMP support in the llvm ports, and I may be open to enabling that for i386 and amd64 when the dust settles. If OPENMPI is required, that would still need gfortran.
I would think that people doing intensive computations that require these options are probably going to custom build to get the most out of their machines anyways. Given the toolchain burdens, I just don't think they are good default options for the average user at the moment.
(In reply to Jason E. Hale from comment #1)
I think you meant to set feedback → maintainer-feedback- I agree, introducing large dependencies isn't a good thing.
There is the port science/cp2k that needs these libraries, so I'm thinking how to accommodate this.
My next idea is to create ports math/fftw3-openmp and math/fftw3-openmpi that would build only whatever OPENMP/OPENMPI options add to math/fftw3 now.
But there are other ports, like math/fftw3-float, that should be merged into math/fftw3. It appears that you have flavors ready in math/fftw3, but they aren't enabled. Are you planning to enable flavors?
(In reply to Yuri Victorovich from comment #2)
> I think you meant to set feedback → maintainer-feedback- I agree, introducing large dependencies isn't a good thing.
I meant to set '+' in maintainer-feedback. If you read the tooltip for maintainer-feedback (hover over with mouse), it should be set to '+' if the maintainer provides feedback (which I have) and to avoid maintainer timeout.
> There is the port science/cp2k that needs these libraries, so I'm thinking how to accommodate this.
I looked at your port and openmp support is optional. Perhaps it is recommended, but still optional. I'll attach a patch you can use in cp2k to at least allow the user to build their own package with openmp in poudriere. Even if OPENMP was on by default in fftw3, you should add this safeguard anyways in case the user turned it off.
> My next idea is to create ports math/fftw3-openmp and math/fftw3-openmpi that would build only whatever OPENMP/OPENMPI options add to math/fftw3 now.
Honestly, I don't think it is worth the effort. These ports are hacked up enough to get them to do what they do now and we really don't need 11 fftw3 ports. Like I said, people running software like this would benefit more from compiling their own fftw3 package to get the SSE optimizations. It is trivial to just enable the wanted options.
> But there are other ports, like math/fftw3-float, that should be merged into math/fftw3. It appears that you have flavors ready in math/fftw3, but they aren't enabled. Are you planning to enable flavors?
In fftw3, "flavors" is a term that upstream uses for the various precision libraries (default, float, long, quad). It has been that way long before ports FLAVORS were introduced and they have nothing to do with each other. I have no current plans to turn the slave ports into FLAVORS since there is little to no benefit. All dependent ports would have to be adjusted. Some ports only depend on the headers from the default "flavor" (audio/liblastfm, for example) and they would have to be fixed.
Created attachment 197087 [details]
science/cp2k openmp safeguard
A commit references this bug:
Date: Fri Sep 14 07:58:06 UTC 2018
New revision: 479762
science/cp2k: Require the option OPENMP=on in fftw3 for options OPENMP and OPENMP_MPI
Submitted by: jhale