mpi portgroup fails to select a C compiler variant if the default is disallowed

[jmroot (Joshua Root)]

For example:

% port info sundials compiler.blacklist=clang
sundials @5.8.0 (math, devel)
Variants:             [+]accelerate, atlas, clang10, clang11, clang12, clang13,
                      clang90, debug, doc, examples, g95, gcc10, gcc11, gcc9,
                      [+]gfortran, [+]mpich, openblas, openmpi, universal
…

One of the clang variants should be selected, but instead, mpi.name just ends up empty. The first noticeable symptom of this for users is the pre-configure variant check failing with a confusing message:

Error: active_variants: Error: invalid port depspec ''
Error:   expecting either: port or (bin|lib|path):foo:port
Error:  has a different Fortran variant () than the one selected, gcc11 (via +gfortran).
Error: Failed to configure sundials: Install  +gcc11

configure.compiler seems to be left as clang-14 (which is not supported by the mpi ports) due to no variant being selected.

[jmroot (Joshua Root)]

Note that the use of compiler.blacklist is just so I could demonstrate this on macOS 12; the same thing will happen on older OS versions if e.g. compiler.cxx_standard is set to something more recent, as sundials does.

[eborisch (Eric A. Borisch)]

I’ve been busy and haven’t had a chance to poke at this; if we had clang-14 mpi flavors would that resolve this issue?

[Christopher Nielsen <mascguy@…>]

In eeb9ff6ea59f6f6a297a8e0555160cb2e6ed251e/macports-ports (master):

openmpi/mpich: add support for clang-14

• CC: @eborisch

See: #65269

[Christopher Nielsen <mascguy@…>]

In ebe26d3bf3b5c653681c190b6b609b34eed442da/macports-ports (master):

pg mpi: add support for clang-14

• CC: @eborisch

See: #65269

[mascguy (Christopher Nielsen)]

Replying to eborisch:

I’ve been busy and haven’t had a chance to poke at this; if we had clang-14 mpi flavors would that resolve this issue?

While clang-14 isn't quite as rock-solid as I'd like it to be - we still need to add a patch to fix issue:65246, for example - hopefully it's reliable enough to add it to the mix.

Josh, does this eliminate the issue you're seeing?

[jmroot (Joshua Root)]

Replying to mascguy:

Josh, does this eliminate the issue you're seeing?

In this specific instance, yes, but it will just come back next time a new clang version is added. The portgroup really needs to do something sensible when configure.compiler is set to a compiler it doesn't know about.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

In this specific instance, yes, but it will just come back next time a new clang version is added. The portgroup really needs to do something sensible when configure.compiler is set to a compiler it doesn't know about.

My thought is that we should coordinate when making a new Clang version the default. In particular, we should first add new MPI subports to openmpi and mpich, and vet those out.

Once we're confident that all is well, then - and only then - update the default Clang.

Thoughts?

[jmroot (Joshua Root)]

Or you could pick a default variant to use when the user hasn't chosen one and the default configure.compiler doesn't match one.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

Or you could pick a default variant to use when the user hasn't chosen one and the default configure.compiler doesn't match one.

Sounds reasonable, though I could use some guidance relative to the heuristics: Given the intricacies of compiler selection and such - and how easy it would be to break all of our MPI-dependent ports - I'd definitely want to collaborate via a PR as well. (Perhaps I'm over-thinking this, but better to be safe...)

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets