New port submission: nfft-3

[macports@…]

G'day,

I'm submitting a new Portfile for inclusion in the MacPorts registry. It allows to build the NFFT library for computing non-equispaced fast Fourier transforms (see ​http://www.nfft.org).

Please let me know if anything needs fixing or improvement.

Best,

Jens Keiner

[dstrubbe (David Strubbe)]

This appears to be the same software as #45385. Can you two discuss and find a consensus for a Portfile, on the page for #45385?

Is "jk" you? Writing the maintainer name like that suggests there is an email address jk@… -- is there one? It's not the email you used in submitting this ticket.

[dstrubbe (David Strubbe)]

Cc Me!

[petrrr]

Cc Me!

[petrrr]

Cc Me!

[petrrr]

Cc Me!

[petrrr]

Cc Me!

[macports@…]

Hi,

yes, this is the same library as #45385. I haven't checked the other port file closely yet, but I'll do that. I wasn't aware somebody had already proposed a new port.

Regarding the maintainers field: Should I put my full email address there? You're right, jk@… doesn't exist. I'm one of the maintainers of this software library, I believe the other ticket must have been created by someone outside our team.

I'll get back with an updated Portfile.

Best,

Jens

[dstrubbe (David Strubbe)]

Yes, in the maintainers field you put a full email address unless you are a committer. See ​https://guide.macports.org/#reference.keywords.maintainers.

Do you really need autoreconf?

Do you want one of the variants to be a default? What is the situation if not Gaussian/B-spline/sinc?

I am interested in this port since it is an optional dependency to Octopus, for which I am a developer and I maintain the port.

[macports@…]

Updated Portfile

[macports@…]

I have updated the portfile:

• The link to the Github sources now points to the latest stable release, which is NFFT 3.3.0.
• The checksums have been updated accordingly.
• The maintainers field has been updated with a valid email address. Note that this is different from my address used in this ticketing system. This is intentional.
• I have added the variant "kaiserbessel" to use the Kaiser-Bessel window function. This was and is always the default for NFFT. I haven't included "kaiserbessel" in default_variants since the variants to select the different window functions all conflict with each other.

Yes, I need to activate the use_autoreconf option since the archive downloaded from Github will not contain a ready-to-use configure script. This has to be generated first.

[dstrubbe (David Strubbe)]

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

Should this port really be called "nfft-3"? The website, and other references I have seen to the library, just call it "nfft".

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.

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.

Can you add a test phase? We should have one for all software for numerical calculations.

I have added "openmaintainer" as per the Guide: "Port maintainers who are not committers are encouraged to add <openmaintainer> to their ports."

[macports@…]

Thanks for the update and hints.

Replying to 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.

[macports@…]

Shall I re-open this ticket or should we continue and use #45385?

[dstrubbe (David Strubbe)]

The test phase is not run as part of the normal build process, so I don't think you need to be concerned about either of the two points you raise -- this is unlike Debian where I think the test is part of the build. In Macports, doing 'port test nfft-3' is a separate action from 'port install nfft-3'. The users decide for themselves afterward what conclusion they draw about test failures. I think an incomplete testsuite is still better than none.

[dstrubbe (David Strubbe)]

Committed in r144695 (with addition of ability to select C compiler). Still, it would be good to add a test phase.

[dstrubbe (David Strubbe)]

Test phase was added in r148677.