Build Petsc with Shared Libraries

Sean Farley sean.michael.farley at gmail.com
Thu Jul 19 14:41:23 PDT 2012


> I see that you use many variants in your Portfile. As a rule of thumb most functionality should be enabled by default. Couldn’t most be enabled by default (possibly as a default_variant)?

Sure; I have no preference either way. My only note is that the
--download-* options shouldn't be used for PETSc since that could lead
to conflicting symbols.

> I like your mpi PortGroup [1]. I can see that could be helpful for other packages as well.

Thanks :-) Yes, my goal with the MPI PortGroup was to unify the use of
+gcc47, +mpi, etc. so that (hopefully) a portfile wouldn't need to
specify any custom compiler variant (ala +gcc4X). I haven't decided on
a nice way to specify that mpi is optional (similarly, how to specify
fortran is optional).

> Isn’t MPI support something that should be enabled by default for Petsc?

It doesn't really matter one way or the other. If no MPI is specified
to PETSc, then it will use its own internal MPI (via MPIUNI).

> Is there any consensus within the MacPorts community on what should be the default MPI implementation used in ports that require MPI?

Good question. Due to the latest few releases of OpenMPI not being
valgrind clean, PETSc recommends mpich2 (well, that and the fact that
the mpich guys are on the next floor to the petsc team).

Following up with mpi, it should be noted that lam, lammpi, and mpich
are all deprecated (and should be removed / replaced_by).


More information about the macports-users mailing list