[petsc-dev] Install location for MPIUNI mpi.h

[Satish Balay]

On Wed, 25 Apr 2018, Jed Brown wrote:

> Satish Balay <balay at 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]

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