On Wed, 25 Apr 2018, Jed Brown 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.
Well in this context MPIUNI behaves like any other externalpackage. > 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. We already have this conflict when switching between mpich and openmpi [so this issue would extend to mpiuni] > > I would rather that petscsys.h include <petsc/mpiuni/mpi.h> because it > can't be used without PETSc and nobody who ever wrote #include <mpi.h> > in their own code will be happy if they get MPIUNI. The reason for using supporting '#include <mpi.h>' - is so that user codes that might use '#include <mpi.h>' would also work with mpiuni build of petsc. Yeah - tradeoffs for each choice - so we settled on the current one - with petsc-makefile usage as the primary supported mode for users. This issue does not come up for such users. And non-petsc-makefile users were to grab all the flags from petsc makefiles and use them anyway. This issue is primarily comes up for users who expect the following to work [which never worked portably] gcc -Ipath_to_petsc_include -Lpath_to_petsc_lib -lpetsc Satish