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

[Barry Smith]

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?

     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