[petsc-dev] forget about libmpiuni completely

[Barry Smith]

On Feb 17, 2010, at 10:32 AM, Lisandro Dalcin wrote:

> On 17 February 2010 13:06, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> On Feb 17, 2010, at 9:05 AM, Lisandro Dalcin wrote:
>>
>>> On 17 February 2010 11:45, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>>>
>>>> 1) Make mpiuni truly a download package mimicing other ones  
>>>> exactly.
>>>> 2) Swallow mpiuni more completely into PETSc, no separate  
>>>> libmpiuni, put
>>>> the
>>>> includes/mods in a location they are found automatically without  
>>>> the
>>>> extra
>>>> -IXXXX
>>>> 3) Have a half-plant/half-animal model.
>>>>
>>>
>>> I definitely vote for (2) ... No separate libmpiuni (put stuff
>>> libpetscsys), put mpi.*.* in  ${PETSC_ARCH}/include/
>>>
>>> However, just in case (think of ./configure --with-mpi=0 --prefix=/ 
>>> usr)
>>> ...
>>>
>>> I think we could do the following:
>>>
>>> 1) rename/move "include/mpiuni/mpi.h" to "include/mpiuni.h"
>>>
>>> 2) autogenerate a header file "$PETSC_ARCH/include/petscmpi.h",
>>> #include'ing "mpi.h" or "mpiuni.h" depending on configuration.
>>>
>>> 3) Change "petsc.h" to #incluide "petscmpi.h" instead of "mpi.h"
>>
>>   Yuck. Users often like to shove a #include "mpi.h" into their  
>> source code
>> (even though, of course, when you include petsc.h you don't need to  
>> worry
>> about that), with your model it pushes people too much into a  
>> "PETSc way".
>>
>>   Your model is clean, but too idealistic I think and would annoy  
>> people.
>>
>
> But if they shove a #include "mpi.h" into their source code, things
> will work, as long as they use a true MPI implementation... My point
> is that if users do want to maintain its code mpiuni-compatible, they
> should not #include "mpi.h", and let #include "petsc.h" handle the MPI
> details...

    I don't want to force them to do that.

    Barry

>
> Anyway, I'm fine with having $PETSC_ARCH/include/mpi*.* ... It's just
> that I have a bit of fear about a prefix PETSc install --with-mpi=0
> overwriting the mpi.h from a true MPI installation... I know, this
> situation is kinda nonsense, but you know...
>
>
> -- 
> Lisandro Dalcin
> ---------------
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594