[MacPorts] #62807: openmpi/mpich: refactor duplicated logic, and simplify ports, via new portgroup
MacPorts
noreply at macports.org
Fri May 7 19:16:39 UTC 2021
#62807: openmpi/mpich: refactor duplicated logic, and simplify ports, via new
portgroup
----------------------------+----------------------
Reporter: mascguy | Owner: mascguy
Type: enhancement | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: openmpi mpich |
----------------------------+----------------------
Comment (by eborisch):
I'm all for them targeting the same set of compilers; what's the current
delta?
Another thought: I've been toying with the idea of having all the non-
default (-clang*, etc) flavors use the ''default'' libraries and headers
rather than build their own, with a defaulted-on ''+wrapperonly'' variant.
In this mode, we would just make copies of {{{mpicc}}}, {{{mpicxx}}}, etc.
with the appropriate changes to CC/CXX etc. in the script (and continue to
depend upon the compilers to make sure they are installed.) Executables
like {{{mpiexec}}} could just be a symlink to the ''-default''
{{{mpiexec}}} (likely easier to maintain than having a separate set of
''select'' files for the variants).
It's typically rare interested in seeing how the different compilers do at
generating the MPI libraries themselves, and you're more interested in
using the features of a particular compiler for your (or another port's)
code. This would drastically cut down the overhead for having multiple
flavors of the wrappers around, while still leaving the options of
disabling the variant if you want a full build of MPI libraries by that
compiler.
It looks like openmpi uses a binary mpicc (symlinked to a binary,
actually), so I'm not sure how easy this would be to implement on openmpi,
but it should be fairly easy on mpich.
--
Ticket URL: <https://trac.macports.org/ticket/62807#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list