[petsc-dev] forget about libmpiuni completely

[Barry Smith]

On Feb 16, 2010, at 10:59 PM, Satish Balay wrote:

> On Tue, 16 Feb 2010, Satish Balay wrote:
>
>> On Tue, 16 Feb 2010, Barry Smith wrote:
>>
>>>
>>> Satish,
>>>
>>>  Why not get rid of libmpiuni completely? Just stick the code into
>>> libpetscsys.a for multiple libraries and libpetsc.a for one library.
>>
>> Well we still have additional -I${PETSC_DIR}/include/mpiuni - to deal
>> with. [as we want to support mpi.h and mpif.h from user code aswell].
>
> forgot about mpi.mod in that list.

    Actually we could handle these by putting the resulting mpi*.*  
into ${PETSC_ARCH}/include like with other external packages.

>
>>
>> Plus - having a separate library name is still consistant with
>> 'multiple libraries in PETSc' scheme - so I don't see a conflict
>> here. [perhaps it should be libpetscmpiuni.a]
>>
>> But if you feel strongly merging it into libpetscsys improves things,
>> I won't object.
>>
>>>  Simplifies life if you want to stick with mpiuni just being "part  
>>> of PETSc"
>>> instead of its own beast.
>>>
>>>  Now it is part plant/part animal; since you strongly rejected my  
>>> plan to
>>> make it all animal let's make it all plant (PETSc).
>>
>> I'll also remove my previous objection to haivng 'download- 
>> mpiuni' [as
>> long as --with-mpi=0 is preserved].
>>
>> The thing I was pointing to in my earlier discussion is - your
>> sugestion doesn't really improve things - as you would be replacing
>> one partly-overloaded option 'with-mpi=0' [the overloading is  
>> internal
>> organzation within petsc - not user interface] with a partly- 
>> ambiguous
>> option 'download' part of 'download-mpiuni'. And your sugestion
>> results in part-plant/part-animal as the current status.
>
> I should have clarified the ambiguity I refer to. Wrt to user
> interface the follwoing ambiguity exists:
>
> - there is no tarball to download. And the functionality
>  --download-mpiuni=foo.tar.gz won't exist.

    Actually there would be, if we organized it that way. Which we  
would.
>
> Wrt internal organization - there wont' be externalpacakges/MPIUNI -
> one would expect when using -download-mpiuni=1

    Sure, there could be if we organized it that way.

    We can organize it any way we want. Two possibilities

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.

   more below

>
> Satish
>
>>
>> So - looks like - if you want a proper organisation, mpiuni should be
>> a proper separate package - and should not rely on PETSc build stuff
>> [and petscconf.h], and can be properly supported by download-mpiuni
>> option. Sometime back - we decided against treating MPIUNI as a
>> separate pacakge to simplify its code maintainance.
>>
>> Note: I would have liked to have libmpiuni.a as separate library even
>> with --with-single-library=1 - but due to the way
>> --with-single-library=1 is done - its not possible - so I gave up on
>> that.

    If there is no libmpiuni with a single library then there should  
be none with several libraries, otherwise it is confusingly  
inconsistent.

   Barry

>>
>> Satish
>>
>