[petsc-dev] PETSc 3.5.0 compilation on Windows and OpenMP with pthread

[Dave Nystrom]

Satish Balay writes:
 > I'll be disabling these in petsc-3.5 [patch update]
 > 
 > Are you sure you need to use 'next' - and not 'master'?

I might very well be able to use master.  I've just been in the habit of
using next because I often uncover issues that you guys fix on the next
branch and that I want without having to wait a day for them to show up in
master.

Dave

 > [sorry I don't remember the discussion on why you needed next]
 > 
 > Satish
 > 
 > On Thu, 3 Jul 2014, Dave Nystrom wrote:
 > 
 > > So what exactly do you mean when you say to turn off the support for the
 > > current pthreads support because I have been using it, such as it is, in
 > > the next branch?
 > > 
 > > > -------- Original Message --------
 > > > Subject: Re: [petsc-dev] PETSc 3.5.0 compilation on Windows and OpenMP
 > > > with pthread
 > > > From: Barry Smith <bsmith at mcs.anl.gov>
 > > > Date: Thu, July 03, 2014 10:08 am
 > > > To: Jed Brown <jed at jedbrown.org>
 > > > Cc: "petsc-dev at mcs.anl.gov" <petsc-dev at mcs.anl.gov>
 > > > 
 > > > 
 > > > On Jul 3, 2014, at 8:37 AM, Jed Brown <jed at jedbrown.org> wrote:
 > > > 
 > > > > Satish Balay <balay at mcs.anl.gov> writes:
 > > > >> threadcomm.py is disabled in petsc3.4, 3.5. Should pthreadclasses.py also be
 > > > >> disabled? [should openmp.py also be disabled?]
 > > > >> 
 > > > >> https://bitbucket.org/petsc/petsc/commits/6e5884b57154c4018286842049a07306848380f9#chg-config/PETSc/packages/threadcomm.py
 > > > > 
 > > > > Yes, they can't do anything but cause confusion right now, and the
 > > > > legacy "pthreadclasses" option should go away.
 > > > 
 > > >    Yes turn them all off.
 > > 
 >