On Apr 15, 2012, at 12:59 PM, Jed Brown wrote:
> On Sun, Apr 15, 2012 at 12:52, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Curse it, these are all cases of MPI didn't do something right or some MPI
> implementor got lazy and didn't include something they should have. They
> should really start with MPI. Maybe MPILazyBastards_xxxx() it doesn't seem
> right to name space any of them with PETSc!!!! MPImissing_, MPIFU_ (for MPI
> fuck up).
>
> MPIPetsc_xxx so it's at least clear who is providing the "fixed" version (and
> which package's configure it may depend on). MPIU_INT, for example, is
> intimately bound to the way PETSc was configured, so maybe it should be
> MPIPETSC_INT?
So MPIPetsc_xxx() for functions and MPIPETSC_XXX for "macro-like" all caps
names?
Not particularly appealing but I guess it is the right thing to do.
Barry
>
>
> > PetscMPI_Iallreduce(), Petsc_MPI_Iallreduce(),
>
> This is a clash between two naming conventions, the silly MPI one with _
> and the reasonable Petsc one without a million _. You know the one I like.
>
> Are you sure we shouldn't continue to use MPIU? We have squatters rights
> to that prefix since we've used it for 18 years. It looks good and makes
> clear what those functions are for.
>
> It's true, but it would be a shame for some version of PETSc to become
> incompatible with some version of MPICH due to a symbol collision (though
> they use visibility on many platforms, so the symbol can be used within the
> library, but not visible outside).
