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? 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.