Are there any places that call MPI directly, but do not include anything from petsc-private? On Jan 21, 2013 6:27 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > On Jan 21, 2013, at 5:41 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > > > On Mon, Jan 21, 2013 at 5:31 PM, Matthew Knepley <knepley at gmail.com> > wrote: > > On Mon, Jan 21, 2013 at 4:12 PM, Karl Rupp <rupp at mcs.anl.gov> wrote: > > Dear PETScians, > > > > MPI 3.0 *removes* a set of functions from MPI 1.x, of which the > following are in use in PETSc: > > > > * MPI_Type_struct, used in > > src/ts/characteristic/impls/da/slda.c > > src/dm/impls/mesh/meshpcice.c > > > > * MPI_Errhandler_create/MPI_Errhandler_set, used in > > src/sys/objects/pinit.c > > src/sys/objects/init.c > > > > In both cases function were renamed in MPI-2.0: > > MPI_Type_struct -> MPI_Type_create_struct > > MPI_Errhandler_create -> MPI_Comm_create_errhandler > > MPI_Errhandler_set -> MPI_Comm_set_errhandler > > Damn assholes, changing their API all the time for no good reason. > > > > > It should be sufficient to update BuildSystem/config/packages/MPI.py and > add the respective checks in configureMPI2(). Any objections on the > following defines: > > HAVE_MPI_TYPE_CREATE_STRUCT > > HAVE_MPI_COMM_CREATE_ERRHANDLER > > HAVE_MPI_COMM_SET_ERRHANDLER > > in the case of success? > > > > Yes, this is the right way. > > > > I'm also in favor of changing all the call sites to the new function > names. I think that if configure does not find a new function name, we can > > > > #define MPI_Type_create_struct(count,lens,displs,types,newtype) > MPI_Type_struct((count),(lens),(displs),(types),(newtype)) > > Yes switch to the new names and have configure generate the old when > needed. I am actually in favor of having configure generate the string > > #define MPI_Type_create_struct(count,lens,displs,types,newtype) > MPI_Type_struct((count),(lens),(displs),(types),(newtype)) > and sticking it in petscconf.h or petscfix.h when needed and not having in > PETSc source/include file code ugly stuff like > > #if !defined(PETSC_HAVE_MPI_TYPE_CREATE_STRUCT) > > #define MPI_Type_create_struct(count,lens,displs,types,newtype) > MPI_Type_struct((count),(lens),(displs),(types),(newtype)) > #endif > > but I am sure Jed will find some objection to having configure generate > the string directly. > > > > > similar to the defines in petsclog.h (though those are for logging) so > that we don't need macros at every call site. FWIW, I'd prefer that the > redefines in petsclog.h be moved to a header that is not mandatory for > users to include (because the current approach cannot be used with another > library that also does the same thing). > > Is this even possible without requiring some "extra" include in each > PETSc source that has to be added? Though I agree in principle with not > having these macros visible in user code I don't like needing some > convoluted "thing" that is different between PETSc source code and user > code; one of the original goals of PETSc design was the user code and PETSc > code were indistinguishable as much as possible both to the human eye and > compilers. So I'd need to see a clean way of handling this that didn't > involve ugly stuff like > #define THIS_BE_PETSC_SOURCE at the top of each PETSc source code file. > > Barry > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130121/77b88ddf/attachment.html>
