[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:
>
>> 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.