I am for a separate mpiuni that get downloaded. I think this makes more sense with<div>our other packages concepts, and is more modular. We can reuse so much more of</div><div>configure as well.</div><div><br></div><div> Matt<br>
<br><div class="gmail_quote">On Wed, Feb 17, 2010 at 6:45 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Feb 16, 2010, at 10:59 PM, Satish Balay wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 16 Feb 2010, Satish Balay wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 16 Feb 2010, Barry Smith wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Satish,<br>
<br>
Why not get rid of libmpiuni completely? Just stick the code into<br>
libpetscsys.a for multiple libraries and libpetsc.a for one library.<br>
</blockquote>
<br>
Well we still have additional -I${PETSC_DIR}/include/mpiuni - to deal<br>
with. [as we want to support mpi.h and mpif.h from user code aswell].<br>
</blockquote>
<br>
forgot about mpi.mod in that list.<br>
</blockquote>
<br>
Actually we could handle these by putting the resulting mpi*.* into ${PETSC_ARCH}/include like with other external packages.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Plus - having a separate library name is still consistant with<br>
'multiple libraries in PETSc' scheme - so I don't see a conflict<br>
here. [perhaps it should be libpetscmpiuni.a]<br>
<br>
But if you feel strongly merging it into libpetscsys improves things,<br>
I won't object.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Simplifies life if you want to stick with mpiuni just being "part of PETSc"<br>
instead of its own beast.<br>
<br>
Now it is part plant/part animal; since you strongly rejected my plan to<br>
make it all animal let's make it all plant (PETSc).<br>
</blockquote>
<br>
I'll also remove my previous objection to haivng 'download-mpiuni' [as<br>
long as --with-mpi=0 is preserved].<br>
<br>
The thing I was pointing to in my earlier discussion is - your<br>
sugestion doesn't really improve things - as you would be replacing<br>
one partly-overloaded option 'with-mpi=0' [the overloading is internal<br>
organzation within petsc - not user interface] with a partly-ambiguous<br>
option 'download' part of 'download-mpiuni'. And your sugestion<br>
results in part-plant/part-animal as the current status.<br>
</blockquote>
<br>
I should have clarified the ambiguity I refer to. Wrt to user<br>
interface the follwoing ambiguity exists:<br>
<br>
- there is no tarball to download. And the functionality<br>
--download-mpiuni=foo.tar.gz won't exist.<br>
</blockquote>
<br>
Actually there would be, if we organized it that way. Which we would.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Wrt internal organization - there wont' be externalpacakges/MPIUNI -<br>
one would expect when using -download-mpiuni=1<br>
</blockquote>
<br>
Sure, there could be if we organized it that way.<br>
<br>
We can organize it any way we want. Two possibilities<br>
<br>
1) Make mpiuni truly a download package mimicing other ones exactly.<br>
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<br>
3) Have a half-plant/half-animal model.<br>
<br>
more below<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Satish<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So - looks like - if you want a proper organisation, mpiuni should be<br>
a proper separate package - and should not rely on PETSc build stuff<br>
[and petscconf.h], and can be properly supported by download-mpiuni<br>
option. Sometime back - we decided against treating MPIUNI as a<br>
separate pacakge to simplify its code maintainance.<br>
<br>
Note: I would have liked to have libmpiuni.a as separate library even<br>
with --with-single-library=1 - but due to the way<br>
--with-single-library=1 is done - its not possible - so I gave up on<br>
that.<br>
</blockquote></blockquote>
<br>
If there is no libmpiuni with a single library then there should be none with several libraries, otherwise it is confusingly inconsistent.<br>
<br>
Barry<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Satish<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>
</div>