nco: add variant esmf to replace accelerate and atlas

[remkos]

Description

Variants accelerate or atlas are obsolete as either LAPACK interface would only be used in association with --enable-esmf, while --disable-esmf was set since nco v4.5.2. So they did not have any impact on the executables.

Now introducing variant esmf which sets --enable-esmf. Since package esmf already has variants accelerate and atlas, to link either libveclibFort or libsatlas, they are not needed here.

This also makes nco compile again on Monterey (without +esmf) as veclibFort does not compile yet on Monterey (https://trac.macports.org/ticket/63717)

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 12.0.1 21A559 x86_64
Xcode Command Line Tools 13.1.0.0.1.1633545042

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Notifying maintainers:
@tenomoto for port nco.

[remkos]

This also satisfies the revbump requested in PR #12807

[remkos]

@reneeotten : maybe you are willing to review and merge under maintainer timeout.

[reneeotten]

@remkos problem is I don't know anything about this port and have no real interest in looking into it. So you're removing both the atlas and accelerate variants with the latter being a default variant. From your description it sounds like they were not working at the moment, but is that a reason to remove them or can they be fixed instead? Adding the new variant is fine I think especially given that people would need to explicitly select it. I guess my main concern here is that after this change there will be no default variant selected anymore unless you specify a MacPorts clang compiler in which case you'll have the default openmp variant - is that what you intended to do (i.e., don't you want to have some "accelaration" by default)?

[remkos]

@reneeotten: In fact no default variant is needed. As you correctly understood the previous default variant accelerate did not do anything, nor did its alternative atlas. The package works fine without selecting any variant at all.

If one would have actually wanted to achieve what atlas or accelerate were to accomplish, then --enable-esmf would have had to be selected. I'm doing that now with variant esmf. That package itself has variants atlas and accelerate, so the particular intent of those two variants for nco is now handled through esmf.

Looking forward to review by @tenomoto or anybody else with interest in nco. @cjones051073 maybe?

[remkos]

Given the maintainer time-out for 8 days, is anybody else willing to approve?
@g5pw
@mf2k
BTW: this is a recurring theme. About 10 of my previous nco PRs ended up with maintainer time-out.

[reneeotten]

Given the maintainer time-out for 8 days, is anybody else willing to approve? @g5pw @mf2k BTW: this is a recurring theme. About 10 of my previous nco PRs ended up with maintainer time-out.

I'll merge this now. If you feel the current maintainer does not respond to tickets/PRs please feel free to file a "port abandoned" ticket; if there is no response to that in about 3 days, you can at least add yourself as maintainer to this port and we can merge things more quickly.