#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