[MacPorts] #40375: new mpich +gcc47 uses clang

MacPorts noreply at macports.org
Thu Sep 5 06:03:04 PDT 2013


#40375: new mpich +gcc47 uses clang
----------------------------+------------------------
  Reporter:  beany_kelly@…  |      Owner:  eborisch@…
      Type:  defect         |     Status:  new
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.2.0
Resolution:                 |   Keywords:
      Port:  mpich          |
----------------------------+------------------------

Comment (by eborisch@…):

 I haven't had a chance to get back to this; perhaps this weekend. I want
 to move over applications to depend on the new mpicc-mp and friends before
 merging the changes back into trunk.

 If you want to try out the new portfiles (mpich (1) and mpich_select (2))
 the links are below.

 For the record, here's how I described them on the mailing list:
 {{{
 I've put (in a separate branch [1]) changes in place to provide
 mpich-default (which creates mpicc-mp, mpicxx-mp, and mpifNN-mp by
 default) as well as a number of mpich-COMPILER ports to be installed
 side-by-side, along with a mpich_select port to facilitate changing
 what mpicc/mpicxx/mpifNN point to for the user. I would (assuming
 people are OK with this approach) have ports that depend on mpich
 (which itself is now a stub and depends on mpich-default) now use
 MPICC=${prefix}/bin/mpicc-mp (or whatever is required for the
 particular package) and depend on path:bin/mpicc-mp:mpich (might be
 satisfied by mpich-devel-default) to insulate packages from the
 current 'port select --set mpich mpich-XXX' setting. All of the
 flavors use mpich-default's headers (and therefore depend on
 mpich-default).

 The mpich-default package builds just like (or at least is intended
 to) the current mpich (system default CC/CXX; variant requested
 fortran (gcc48 by default)) using the "fortran recipe." The other
 mpich-COMPILER flavors are intended for users where mpich is the
 endpoint of MP support, and the tools created are being used for
 "external" work. These wrap the requested CC/CXX in addition to
 fortran (depending on variant; using the recipe for non-gccNN ports,
 and the matching gfortan for the gccNN ones.)

 There is also a set of conflicting mpich-devel packages set up in the same
 way.

 Let me know what you think / if that seems reasonable and I'll make
 the changes (in the branch) to ports depending on mpich and then merge
 everything at once back into trunk.
 }}}

 [https://lists.macosforge.org/pipermail/macports-
 dev/2013-August/024170.html Original message.]

 (1) [source:users/eborisch/dports/science/mpich]
 (2) [source:users/eborisch/dports/sysutils/mpich_select]

-- 
Ticket URL: <https://trac.macports.org/ticket/40375#comment:6>
MacPorts <http://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list