On Mon, Dec 14, 2009 at 8:28 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On Dec 14, 2009, at 8:23 AM, Matthew Knepley wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
On Dec 14, 2009, at 8:16 AM, Matthew Knepley wrote:<br>
<br>
I strongly disagree with this change. I would like to back it out until we<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
discuss it. The correct<br>
thing to do is use --with-shared FOR ALL shared library build requests.<br>
Why should MPI be<br>
different? There is absolutely no need to multiply the mechanisms here.<br>
<br>
</blockquote>
<br>
 Yes there is. I want to build MPI shared libraries but not PETSc shared<br>
libraries.<br>
<br>
</blockquote>
<br>
Why?<br>
</blockquote>
<br></div>
    It doesn't matter why I want to do it.<br>
<br>
    Why the heck does --with-mpi-shared exist if it isn't used to control MPI shared libraries, should we remove it?<font color="#888888"><br></font></blockquote><div><br>If we are using shared libraries, and the MPI shared library was broken, the configure failed. This option was added<br>
to allow the user to turn off that check.<br><br>   Matt<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
    Barry</font><div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
 Matt<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 Barry<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is blowing up a small documentation problem into a big design flaw.<br>
<br>
 Matt<br>
<br>
On Mon, Dec 14, 2009 at 8:14 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
 This is the help message that has always been there<br>
<br>
 help.addArgument('MPI', '-with-mpi-shared=<bool>',<br>
   nargs.ArgBool(None, None, 'Try to use shared MPI libraries'))<br>
<br>
Note the word   TRY! How can you TRY to use shared MPI libraries if you<br>
don't build the shared MPI libraries. TRY means make some effort, if you<br>
don't make the MPI libraries with shared then your are not trying!<br>
<br>
Feel free to add a new option --with-mpi-shared-test if you want, for<br>
your weird case; where you want to use shared libraries but don't want to<br>
build them.<br>
<br>
<br>
Barry<br>
<br>
<br>
On Dec 13, 2009, at 10:19 PM, Matthew Knepley wrote:<br>
<br>
On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
<br>
So if I pass --with-mpi-shared into MPI.py it TESTS if the MPI libraries<br>
are shared. Fine. But if it is download-mpich IT DOES NOT try to make<br>
shared<br>
libraries for MPICH. It only tries to make shared libraries for MPI if<br>
--with-shared is passed. WTF?<br>
<br>
<br>
--with-mpi-shared is a workaround option. Perhaps it should be renamed. It<br>
was only put in to avoid the shared library test.<br>
<br>
<br>
So I change it so that it tries to make mpi shared libraries if<br>
--with-mpi-shared is passed but not also --with-shared. What happens?<br>
"Configuring with shared libraries - but the system/compilers do not<br>
support this." How the hell does it know the system/compilers do not<br>
support<br>
this? So I have to change the code to not reject the --with-mpi-shared<br>
when<br>
using static libraries.<br>
<br>
<br>
Wait, don't make that change. --with-mpi-shared should NOT control<br>
anything<br>
but the test.<br>
<br>
<br>
Sometimes I just want to delete the whole stinking repository of crud<br>
piled on crap piled on crud. Maybe we need to start having code reviews<br>
instead of shoving random code into random files and hope that sometimes<br>
things might work.<br>
<br>
Ok, well I shoved some random code in and got it to behave reasonably for<br>
me, until tomorrow,<br>
<br>
Barry<br>
<br>
This problem caused my early problem, since it ignored the<br>
--with-mpi-shared option it did not think it needed to rebuild mpich.<br>
<br>
<br>
I do not understand this. Can we rollback this change and discuss it?<br>
<br>
Matt<br>
<br>
--<br>
What most experimenters take for granted before they begin their<br>
experiments<br>
is infinitely more interesting than any results to which their experiments<br>
lead.<br>
-- Norbert Wiener<br>
<br>
On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
So if I pass --with-mpi-shared into MPI.py it TESTS if the MPI libraries<br>
are shared. Fine. But if it is download-mpich IT DOES NOT try to make shared<br>
libraries for MPICH. It only tries to make shared libraries for MPI if<br>
--with-shared is passed. WTF?<br>
<br>
--with-mpi-shared is a workaround option. Perhaps it should be renamed. It<br>
was only put in to avoid the shared library test.<br>
<br>
So I change it so that it tries to make mpi shared libraries if<br>
--with-mpi-shared is passed but not also --with-shared. What happens?<br>
"Configuring with shared libraries - but the system/compilers do not<br>
support this." How the hell does it know the system/compilers do not support<br>
this? So I have to change the code to not reject the --with-mpi-shared when<br>
using static libraries.<br>
<br>
Wait, don't make that change. --with-mpi-shared should NOT control<br>
anything but the test.<br>
<br>
Sometimes I just want to delete the whole stinking repository of crud<br>
piled on crap piled on crud. Maybe we need to start having code reviews<br>
instead of shoving random code into random files and hope that sometimes<br>
things might work.<br>
<br>
Ok, well I shoved some random code in and got it to behave reasonably for<br>
me, until tomorrow,<br>
<br>
Barry<br>
<br>
This problem caused my early problem, since it ignored the<br>
--with-mpi-shared option it did not think it needed to rebuild mpich.<br>
<br>
I do not understand this. Can we rollback this change and discuss it?<br>
<br>
Matt<br>
<br>
--<br>
What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which their<br>
experiments lead.<br>
-- Norbert Wiener<br>
<br>
<br>
<br>
<br>
--<br>
What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which their<br>
experiments lead.<br>
-- Norbert Wiener<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
-- <br>
What most experimenters take for granted before they begin their experiments<br>
is infinitely more interesting than any results to which their experiments<br>
lead.<br>
-- Norbert Wiener<br>
<br>
On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
On Dec 14, 2009, at 8:16 AM, Matthew Knepley wrote:<br>
<br>
I strongly disagree with this change. I would like to back it out until we discuss it. The correct<br>
thing to do is use --with-shared FOR ALL shared library build requests. Why should MPI be<br>
different? There is absolutely no need to multiply the mechanisms here.<br>
<br>
  Yes there is. I want to build MPI shared libraries but not PETSc shared libraries.<br>
<br>
Why?<br>
<br>
  Matt<br>
<br>
  Barry<br>
<br>
<br>
<br>
This is blowing up a small documentation problem into a big design flaw.<br>
<br>
  Matt<br>
<br>
On Mon, Dec 14, 2009 at 8:14 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
  This is the help message that has always been there<br>
<br>
  help.addArgument('MPI', '-with-mpi-shared=<bool>',                           nargs.ArgBool(None, None, 'Try to use shared MPI libraries'))<br>
<br>
 Note the word   TRY! How can you TRY to use shared MPI libraries if you don't build the shared MPI libraries. TRY means make some effort, if you don't make the MPI libraries with shared then your are not trying!<br>

<br>
 Feel free to add a new option --with-mpi-shared-test if you want, for your weird case; where you want to use shared libraries but don't want to build them.<br>
<br>
<br>
 Barry<br>
<br>
<br>
On Dec 13, 2009, at 10:19 PM, Matthew Knepley wrote:<br>
<br>
On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
<br>
 So if I pass --with-mpi-shared into MPI.py it TESTS if the MPI libraries<br>
are shared. Fine. But if it is download-mpich IT DOES NOT try to make shared<br>
libraries for MPICH. It only tries to make shared libraries for MPI if<br>
--with-shared is passed. WTF?<br>
<br>
<br>
--with-mpi-shared is a workaround option. Perhaps it should be renamed. It<br>
was only put in to avoid the shared library test.<br>
<br>
<br>
 So I change it so that it tries to make mpi shared libraries if<br>
--with-mpi-shared is passed but not also --with-shared. What happens?<br>
"Configuring with shared libraries - but the system/compilers do not<br>
support this." How the hell does it know the system/compilers do not support<br>
this? So I have to change the code to not reject the --with-mpi-shared when<br>
using static libraries.<br>
<br>
<br>
Wait, don't make that change. --with-mpi-shared should NOT control anything<br>
but the test.<br>
<br>
<br>
 Sometimes I just want to delete the whole stinking repository of crud<br>
piled on crap piled on crud. Maybe we need to start having code reviews<br>
instead of shoving random code into random files and hope that sometimes<br>
things might work.<br>
<br>
 Ok, well I shoved some random code in and got it to behave reasonably for<br>
me, until tomorrow,<br>
<br>
 Barry<br>
<br>
This problem caused my early problem, since it ignored the<br>
--with-mpi-shared option it did not think it needed to rebuild mpich.<br>
<br>
<br>
I do not understand this. Can we rollback this change and discuss it?<br>
<br>
 Matt<br>
<br>
-- <br>
What most experimenters take for granted before they begin their experiments<br>
is infinitely more interesting than any results to which their experiments<br>
lead.<br>
-- Norbert Wiener<br>
<br>
On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br>
<br>
 So if I pass --with-mpi-shared into MPI.py it TESTS if the MPI libraries are shared. Fine. But if it is download-mpich IT DOES NOT try to make shared libraries for MPICH. It only tries to make shared libraries for MPI if --with-shared is passed. WTF?<br>

<br>
--with-mpi-shared is a workaround option. Perhaps it should be renamed. It was only put in to avoid the shared library test.<br>
<br>
 So I change it so that it tries to make mpi shared libraries if --with-mpi-shared is passed but not also --with-shared. What happens?<br>
"Configuring with shared libraries - but the system/compilers do not support this." How the hell does it know the system/compilers do not support this? So I have to change the code to not reject the --with-mpi-shared when using static libraries.<br>

<br>
Wait, don't make that change. --with-mpi-shared should NOT control anything but the test.<br>
<br>
 Sometimes I just want to delete the whole stinking repository of crud piled on crap piled on crud. Maybe we need to start having code reviews instead of shoving random code into random files and hope that sometimes things might work.<br>

<br>
 Ok, well I shoved some random code in and got it to behave reasonably for me, until tomorrow,<br>
<br>
 Barry<br>
<br>
This problem caused my early problem, since it ignored the --with-mpi-shared option it did not think it needed to rebuild mpich.<br>
<br>
I do not understand this. Can we rollback this change and discuss it?<br>
<br>
 Matt<br>
<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>
<br>
<br>
<br>
<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>
<br>
<br>
<br>
<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>
</blockquote>
<br>
</div></div></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>