[petsc-dev] forget about libmpiuni completely

[Satish Balay]

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.

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

Wrt internal organization - there wont' be externalpacakges/MPIUNI -
one would expect when using -download-mpiuni=1

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