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

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> 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]

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.