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

Jed Brown jed at jedbrown.org
Wed Apr 25 14:26:34 CDT 2018


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


More information about the petsc-dev mailing list