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