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

[Lisandro Dalcín]

On Mon, Dec 14, 2009 at 1:33 PM, Matthew Knepley  wrote:
> On Mon, Dec 14, 2009 at 10:28 AM, Lisandro Dalc?n  
> wrote:
>>
>> On Mon, Dec 14, 2009 at 11:34 AM, Matthew Knepley 
>> wrote:
>> >
>> > 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.
>> >
>>
>> What does 'broken' means? How can the lib be broken for configure, but
>> not for linking PETSc or user programs?
>
> It would also be broken there too, and fall back to the static libraries.
>

Sorry, I'm still confused. What does 'broken' means? Sorry about my
ignorance: In the case of a corrupted (whatever that could mean)
shared lib file, does the linker fall back to use a static lib?


-- 
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

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

[Lisandro Dalcín]

On Mon, Dec 14, 2009 at 11:34 AM, Matthew Knepley  wrote:
>
> 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.
>

What does 'broken' means? How can the lib be broken for configure, but
not for linking PETSc or user programs?


-- 
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

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

[Lisandro Dalcín]

On Mon, Dec 14, 2009 at 11:23 AM, Matthew Knepley
 wrote:
> On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith  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?
>

If you build MPI shared but PETSc static, we are still able to use
mpi4py+petsc4py (and stop there, no chance to add slepc4py to the
sum). Using a static PETSc is strongly discouraged, but anyway
possible, provided that MPI is shared.


-- 
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

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

[Barry Smith]

Ok, after tracing through the code I finally understand.

If --with-batch is used (which means programs cannot be run so the  
shared library check can not be done) then --with-mpi-shared is used  
to say if the MPI libraries are shared or not (instead of testing).

The text is MPI.py is TERRIBLE and confusing. First

 help.addArgument('MPI', '-with-mpi- 
shared=',   nargs.ArgBool(None, None,  
'Try to use shared MPI libraries'))

   It does not "Try to use shared libraries". It is a flag to indicate  
if the libraries are shared or not.

   def checkSharedLibrary(self):
 '''Check that the libraries for MPI are shared libraries'''
 self.executeTest(self.configureMPIEXEC)
 try:
   self.shared = self.libraries.checkShared('#include  
\n','MPI_Init','MPI_Initialized','MPI_Finalize',checkLink =  
self.checkPackageLink,libraries = self.lib, defaultArg = 'with-mpi- 
shared', executor = self.mpiexec)
 except RuntimeError, e:
   if self.framework.argDB['with-shared']:
 raise RuntimeError('Shared libraries cannot be built using  
MPI provided.\nEither rebuild with --with-shared=0 or rebuild MPI with  
shared library support')
   self.framework.logPrint('MPI libraries cannot be used with  
shared libraries')
   self.shared = 0
 return

It does not check "that the libraries are shared" it just sets a  
flag indicating if they are shared or not.


I will change the docs to make things clear and introduce a -- 
download-mpich-shared to tell it to make the shared libraries.

Now everyone should be happy,

Will push my fixes shortly.


Barry

On Dec 14, 2009, at 10:40 AM, Matthew Knepley wrote:

> On Mon, Dec 14, 2009 at 10:39 AM, Lisandro Dalc?n  
>  wrote:
> On Mon, Dec 14, 2009 at 1:33 PM, Matthew Knepley   
> wrote:
> > On Mon, Dec 14, 2009 at 10:28 AM, Lisandro Dalc?n  
>  wrote:
> >>
> >> On Mon, Dec 14, 2009 at 11:34 AM, Matthew Knepley  >
> >> wrote:
> >> >
> >> > 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.
> >> >
> >>
> >> What does 'broken' means? How can the lib be broken for  
> configure, but
> >> not for linking PETSc or user programs?
> >
> > It would also be broken there too, and fall back to the static  
> libraries.
> >
>
> Sorry, I'm still confused. What does 'broken' means? Sorry about my
> ignorance: In the case of a corrupted (whatever that could mean)
> shared lib file, does the linker fall back to use a static lib?
>
> I believe so. I know that is why I put this in. The shared lib test  
> would break, since
> they were not functional, but the library overall would work.
>
>   Matt
>
> --
> Lisandro Dalc?n
> ---
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
> -- 
> 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

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

[Matthew Knepley]

On Mon, Dec 14, 2009 at 10:39 AM, Lisandro Dalc?n  wrote:

> On Mon, Dec 14, 2009 at 1:33 PM, Matthew Knepley 
> wrote:
> > On Mon, Dec 14, 2009 at 10:28 AM, Lisandro Dalc?n 
> wrote:
> >>
> >> On Mon, Dec 14, 2009 at 11:34 AM, Matthew Knepley 
> >> wrote:
> >> >
> >> > 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.
> >> >
> >>
> >> What does 'broken' means? How can the lib be broken for configure, but
> >> not for linking PETSc or user programs?
> >
> > It would also be broken there too, and fall back to the static libraries.
> >
>
> Sorry, I'm still confused. What does 'broken' means? Sorry about my
> ignorance: In the case of a corrupted (whatever that could mean)
> shared lib file, does the linker fall back to use a static lib?
>

I believe so. I know that is why I put this in. The shared lib test would
break, since
they were not functional, but the library overall would work.

  Matt


> --
> Lisandro Dalc?n
> ---
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>
-- 
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: 

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

[Matthew Knepley]

On Mon, Dec 14, 2009 at 10:28 AM, Lisandro Dalc?n  wrote:

> On Mon, Dec 14, 2009 at 11:34 AM, Matthew Knepley 
> wrote:
> >
> > 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.
> >
>
> What does 'broken' means? How can the lib be broken for configure, but
> not for linking PETSc or user programs?
>

It would also be broken there too, and fall back to the static libraries.

  Matt


> --
> Lisandro Dalc?n
> ---
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>



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

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

[Matthew Knepley]

On Mon, Dec 14, 2009 at 8:28 AM, Barry Smith  wrote:

>
> On Dec 14, 2009, at 8:23 AM, Matthew Knepley wrote:
>
>  On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith  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 
 wrote:

  This is the help message that has always been there

  help.addArgument('MPI', '-with-mpi-shared=',
   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 
 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 
 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 

[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   
> 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   
>>> wrote:
>>>
>>>  This is the help message that has always been there
>>>
>>>  help.addArgument('MPI', '-with-mpi-shared=',
>>>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   
>>> 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   
>>> 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
>>>

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

[Matthew Knepley]

On Mon, Dec 14, 2009 at 8:21 AM, Barry Smith  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  wrote:
>>
>>   This is the help message that has always been there
>>
>>   help.addArgument('MPI', '-with-mpi-shared=',
>> 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  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  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 resul

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

[Barry Smith]

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.

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   
> wrote:
>
>This is the help message that has always been there
>
>help.addArgument('MPI', '-with-mpi- 
> shared=',   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   
> 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   
> 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

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

[Matthew Knepley]

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.

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

>
>This is the help message that has always been there
>
>help.addArgument('MPI', '-with-mpi-shared=',
> 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  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  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
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[Barry Smith]

 This is the help message that has always been there

 help.addArgument('MPI', '-with-mpi- 
shared=',   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   
> 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   
> 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

stupid, stupid, stupid MPI.py

[Matthew Knepley]

On Sun, Dec 13, 2009 at 9:36 PM, Barry Smith  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
-- next part --
An HTML attachment was scrubbed...
URL: 

stupid, stupid, stupid MPI.py

[Barry Smith]

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?

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.

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.