[petsc-maint #38919] Re: stupid, stupid, stupid MPI.py

[Matthew Knepley]

On Mon, Dec 14, 2009 at 8:28 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Dec 14, 2009, at 8:23 AM, Matthew Knepley wrote:
>
>  On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>
>>> On Dec 14, 2009, at 8:16 AM, Matthew Knepley wrote:
>>>
>>> I strongly disagree with this change. I would like to back it out until
>>> we
>>>
>>>> discuss it. The correct
>>>> thing to do is use --with-shared FOR ALL shared library build requests.
>>>> Why should MPI be
>>>> different? There is absolutely no need to multiply the mechanisms here.
>>>>
>>>>
>>>  Yes there is. I want to build MPI shared libraries but not PETSc shared
>>> libraries.
>>>
>>>
>> Why?
>>
>
>    It doesn't matter why I want to do it.
>
>    Why the heck does --with-mpi-shared exist if it isn't used to control
> MPI shared libraries, should we remove it?
>

If we are using shared libraries, and the MPI shared library was broken, the
configure failed. This option was added
to allow the user to turn off that check.

   Matt


>    Barry
>
>
>
>>  Matt
>>
>>
>>   Barry
>>>
>>>
>>>
>>>  This is blowing up a small documentation problem into a big design flaw.
>>>>
>>>>  Matt
>>>>
>>>> On Mon, Dec 14, 2009 at 8:14 AM, Barry Smith <bsmith at mcs.anl.gov>
>>>> wrote:
>>>>
>>>>  This is the help message that has always been there
>>>>
>>>>  help.addArgument('MPI', '-with-mpi-shared=<bool>',
>>>>   nargs.ArgBool(None, None, 'Try to use shared MPI libraries'))
>>>>
>>>> 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!
>>>>
>>>> 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.
>>>>
>>>>
>>>> Barry
>>>>
>>>>
>>>> On Dec 13, 2009, at 10:19 PM, Matthew Knepley wrote:
>>>>
>>>> On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <bsmith at mcs.anl.gov>
>>>> wrote:
>>>>
>>>>
>>>> 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?
>>>>
>>>>
>>>> --with-mpi-shared is a workaround option. Perhaps it should be renamed.
>>>> It
>>>> was only put in to avoid the shared library test.
>>>>
>>>>
>>>> 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?
>>>> "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.
>>>>
>>>>
>>>> Wait, don't make that change. --with-mpi-shared should NOT control
>>>> anything
>>>> but the test.
>>>>
>>>>
>>>> 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.
>>>>
>>>> Ok, well I shoved some random code in and got it to behave reasonably
>>>> for
>>>> me, until tomorrow,
>>>>
>>>> Barry
>>>>
>>>> This problem caused my early problem, since it ignored the
>>>> --with-mpi-shared option it did not think it needed to rebuild mpich.
>>>>
>>>>
>>>> I do not understand this. Can we rollback this change and discuss it?
>>>>
>>>> Matt
>>>>
>>>> --
>>>> 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
>>>>
>>>> On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <bsmith at mcs.anl.gov>
>>>> wrote:
>>>>
>>>> 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?
>>>>
>>>> --with-mpi-shared is a workaround option. Perhaps it should be renamed.
>>>> It
>>>> was only put in to avoid the shared library test.
>>>>
>>>> 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?
>>>> "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.
>>>>
>>>> Wait, don't make that change. --with-mpi-shared should NOT control
>>>> anything but the test.
>>>>
>>>> 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.
>>>>
>>>> Ok, well I shoved some random code in and got it to behave reasonably
>>>> for
>>>> me, until tomorrow,
>>>>
>>>> Barry
>>>>
>>>> This problem caused my early problem, since it ignored the
>>>> --with-mpi-shared option it did not think it needed to rebuild mpich.
>>>>
>>>> I do not understand this. Can we rollback this change and discuss it?
>>>>
>>>> Matt
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>>
>>
>> --
>> 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
>>
>> On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>> On Dec 14, 2009, at 8:16 AM, Matthew Knepley wrote:
>>
>> I strongly disagree with this change. I would like to back it out until we
>> discuss it. The correct
>> thing to do is use --with-shared FOR ALL shared library build requests.
>> Why should MPI be
>> different? There is absolutely no need to multiply the mechanisms here.
>>
>>  Yes there is. I want to build MPI shared libraries but not PETSc shared
>> libraries.
>>
>> Why?
>>
>>  Matt
>>
>>  Barry
>>
>>
>>
>> This is blowing up a small documentation problem into a big design flaw.
>>
>>  Matt
>>
>> On Mon, Dec 14, 2009 at 8:14 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>  This is the help message that has always been there
>>
>>  help.addArgument('MPI', '-with-mpi-shared=<bool>',
>>     nargs.ArgBool(None, None, 'Try to use shared MPI libraries'))
>>
>>  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!
>>
>>  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.
>>
>>
>>  Barry
>>
>>
>> On Dec 13, 2009, at 10:19 PM, Matthew Knepley wrote:
>>
>> On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>
>>  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?
>>
>>
>> --with-mpi-shared is a workaround option. Perhaps it should be renamed. It
>> was only put in to avoid the shared library test.
>>
>>
>>  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?
>> "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.
>>
>>
>> Wait, don't make that change. --with-mpi-shared should NOT control
>> anything
>> but the test.
>>
>>
>>  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.
>>
>>  Ok, well I shoved some random code in and got it to behave reasonably for
>> me, until tomorrow,
>>
>>  Barry
>>
>> This problem caused my early problem, since it ignored the
>> --with-mpi-shared option it did not think it needed to rebuild mpich.
>>
>>
>> I do not understand this. Can we rollback this change and discuss it?
>>
>>  Matt
>>
>> --
>> 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
>>
>> On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>  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?
>>
>> --with-mpi-shared is a workaround option. Perhaps it should be renamed. It
>> was only put in to avoid the shared library test.
>>
>>  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?
>> "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.
>>
>> Wait, don't make that change. --with-mpi-shared should NOT control
>> anything but the test.
>>
>>  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.
>>
>>  Ok, well I shoved some random code in and got it to behave reasonably for
>> me, until tomorrow,
>>
>>  Barry
>>
>> This problem caused my early problem, since it ignored the
>> --with-mpi-shared option it did not think it needed to rebuild mpich.
>>
>> I do not understand this. Can we rollback this change and discuss it?
>>
>>  Matt
>>
>> --
>> 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
>>
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> --
>> 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
>>
>
>


-- 
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/20091214/6394c500/attachment.html>