Satish Balay <ba...@mcs.anl.gov> writes: > 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]
You mean if someone --download-mpich and then manually installs Open MPI to the same prefix, overwiting the MPICH header? Note that the option isn't --download-mpiuni, it's --with-mpi=0. >> 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. If a user does this and doesn't link PETSc, it literally won't work. I conjecture that nobody that writes #include <mpi.h> in their code will be happy if they get MPIUNI. > 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 It works now (as long as you use shared libraries), modulo MPI.