On Wed, 25 Apr 2018, Jed Brown wrote: > Satish Balay <[email protected]> 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?
Yes [and more generally with non-prefix install] > > Note that the option isn't --download-mpiuni, it's --with-mpi=0. Yes - and configure deals with it like externalpackage [wrt other dependencies] > > >> 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. I'm not sure how many externalpackages work with mpiuni with '#include <mpi.h>' > > 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. i.e its a small subset of all use cases [prefix install + shared libraires + all externalpackages are also shared] Note: for regular non-prefix install - there is the extra -I$PETSC_DIR/$PETSC_ARCH/include [or you could say I$PETSC_DIR/include is the extra one that would have to be explicitly listed] Satish
