[petsc-dev] forget about libmpiuni completely

[Matthew Knepley]

I am for a separate mpiuni that get downloaded. I think this makes more
sense with
our other packages concepts, and is more modular. We can reuse so much more
of
configure as well.

  Matt

On Wed, Feb 17, 2010 at 6:45 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100217/cb53f8b3/attachment.html>