"Smith, Barry F." <bsm...@mcs.anl.gov> writes: >> On Apr 25, 2018, at 2:31 PM, Jed Brown <j...@jedbrown.org> wrote: >> >> "Smith, Barry F." <bsm...@mcs.anl.gov> writes: >> >>>> On Apr 25, 2018, at 1:36 PM, Jed Brown <j...@jedbrown.org> wrote: >>>> >>>> It is currently installed to include/petsc/mpiuni/mpi.h and petscsys.h >>>> includes it as <mpi.h>, which means that users of MPIUNI need to put >>>> -I/prefix/include/petsc/mpiuni in their command lines. Matt and I agree >>>> that this is bad. We disagree on the solution. >>>> >>>> He wants to install it to /prefix/include/mpi.h as though the user had >>>> written --download-mpich. This would conflict if a user later installs >>>> a real MPI to that location. >>> >>> Jed, >>> >>> So you propose in petscsys.h ? >>> >>> #if defined(PETSC_HAVE_MPIUNI) >>> #include <petsc/mpiuni/mpi.h> >>> #else >>> #include <mpi.h> >>> #endif >>> >>> I don't have a problem with this. >> >> Yes, and same installation layout as today. > > Ok, this is far better than copying the mpiuni mpi.h file to a > public place (Matt's suggestion) and is a bit better than requiring > the extra -I flag (Satish's suggestion)
Is this okay for 'maint'? It feels aggressive, but I'm having trouble constructing a scenario in which it would break an existing installation or existing code.