[petsc-dev] forget about libmpiuni completely

[Satish Balay]

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

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.

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.

Satish