Satish Balay <ba...@mcs.anl.gov> writes: > If we really have to change - I'm inclined towards Matt's prefered approach. > > [issues with 'dirty builddir' is a separate problem
I don't care about the build directory, I care about the install directory. It should be possible to install serial PETSc to prefix=/usr without conflicting with an MPI that may exist or may later exist. If you want to install something to the public namespace, the option would need to be --download-mpiuni which I think is less desirable for users. When they write --with-mpi=0, it's because they don't want MPI, not that they want to install a dysfunctional MPI. > - it comes up with switching between replaceable packages > [openmpi,mpich,mpiuni] - or switching versions of the same package] > > Satish > > On Wed, 25 Apr 2018, Matthew Knepley wrote: > >> On Wed, Apr 25, 2018 at 2:36 PM, Jed Brown <j...@jedbrown.org> 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. >> > >> > 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. >> > >> >> The idea should be that "installing" means that everyone is using >> compatible things >> from that location. If you allow an MPIUNI PETSc to be installed to a >> location that >> also has another MPI, what does mpiexec in ./bin do? There is just as much >> potential >> for confusion as there is when putting an MPICH PETSc in a location with >> OpenMPI >> installed. >> >> Matt >> >> >> > 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. >> > >> >> >> >>