[MacPorts] #46718: New port submission: nfft-3

[MacPorts]

#46718: New port submission: nfft-3
-------------------------+--------------------------------
  Reporter:  macports@…  |      Owner:  macports-tickets@…
      Type:  submission  |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.3.3
Resolution:  duplicate   |   Keywords:
      Port:  nfft-3      |
-------------------------+--------------------------------

Comment (by macports@…):

 Thanks for the update and hints.

 Replying to [comment:10 dstrubbe@…]:
 > Thanks. You can run "port -v lint --nitpick" to check some things. I
 get:
 > {{{
 > Warning: Maintainer email address should be obfuscated as nfft.org:jens
 > }}}
 Ok, noted.
 > Should this port really be called "nfft-3"? The website, and other
 references I have seen to the library, just call it "pfft".
 NFFT is based on FFTW. There have been different generations of both
 packages. Recent versions of NFFT are all based on FFTW 3.x.x whose port
 is called fftw-3 to distinguish from the older 2.x.x series. I think
 nfft-3 aligns well with that.

 Also, once we would get a new major version 4.x.x (e.g. implied by major
 API changes), it would be useful to be able to keep the previous series
 available under the same name. So, this is a forward looking issue.
 >
 > Why use the Github repo rather than the tarball? https://www-user.tu-
 chemnitz.de/~potts/nfft/download/nfft-3.3.0.tar.gz
 > Then there is a configure script, and autoconf would not be necessary.
 True. I have changed the port file accordingly. The drawback is that we
 have more friction in that updating the download site is still a very
 manual process and not entirely under my control. This is not true for
 GitHub where creating a new tag would suffice to release. Just my two
 cents on this...
 >
 > Regarding the default variant, the normal way to add it when it
 conflicts with other variants is like this:
 > {{{
 > if {![variant_isset gaussian] && ![variant_isset bspline] &&
 ![variant_isset sinc]} {
 >     default_variants-append +kaiserbessel
 > }
 > }}}
 > I fixed up the description which needed newlines.
 Thanks.
 >
 > Can you add a test phase? We should have one for all software for
 numerical calculations.
 We could add a test phase. There's unit tests for some, but not all,
 modules. However, there's some caveats:

 1. It would slow down the build process considerably. We're thinking about
 adding a configure flag to restrict the tests to a quicker subset, but we
 need a new release for that.

 2. The tests could fail even though there's no actual problem. The reason
 is that getting reasonably tight error bounds for the approximate
 algorithms is quite hard. When the bounds are too loose, the tests become
 pointless. If they are too tight, they might fail on any architecture/OS
 combination that we were not able to test. Feedback I'm getting from
 Debian maintainers indicates that the latter is currently the case. I
 wouldn't recommend integrating the test suite until this is sorted out
 properly.

 So I have not yet added a test phase. I hope this is not a blocker for the
 first port file version.
 >
 > I have added "openmaintainer" as per the Guide: "Port maintainers who
 are not committers are encouraged to add <openmaintainer> to their ports."
 Ok.

 Updated port file is attached.

-- 
Ticket URL: <https://trac.macports.org/ticket/46718#comment:11>
MacPorts <https://www.macports.org/>
Ports system for OS X