Satish Balay <ba...@mcs.anl.gov> writes: > On Wed, 25 Apr 2018, Jed Brown wrote: > >> 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? > > 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]
Which coincides with packaged installs. > 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] You can just always give it (they refer to the same directory when PETSC_ARCH is unset) and then it works more generally. Requiring the path to MPIUNI is definitely an outlier.