Of course. I clicked the wrong button. Thanks for the tips. Jim
On Sun, Jun 16, 2013 at 3:15 PM, Jed Brown <jedbr...@mcs.anl.gov> wrote: > Please always use "reply-all" so that your messages go to the list. > This is standard mailing list etiquette. It is important to preserve > threading for people who find this discussion later and so that we do > not waste our time re-answering the same questions that have already > been answered in private side-conversations. You'll likely get an > answer faster that way too. > > Jim Fonseca <jefons...@gmail.com> writes: > > > Hi Jed, > > Thanks. Well, I was just going to paste the new directive functions into > > the petscversion.h we have for our current PETSc 3.2 builds. > > Okay, thanks for explaining. This is now fixed in 'maint' and 'master'. > > > Yes, I know you probably cringe when you read we are still using > > that. :) I wanted to use PETSC_VERSION_GE moving forward since that > > seemed a lot nicer than comparing the version numbers one by one (i.e > > 3.2, 3.3, 3.4, petsc-dev) I want to try the make the transition from > > 3.2 to 3.4 as smooth as possible since we run on a few systems and it > > will be difficult to update all our builds simultaneously (some are > > cluster modules, some use our own PETSc builds) and test them. > > Yup, understood. Depending on how your code includes PETSc headers, you > can do something like this: > > #include <petscsnes.h> /* or whatever */ > > #if !defined(PETSC_VERSION_LT) > #define PETSC_VERSION_LT(MAJOR,MINOR,SUBMINOR) \ > (PETSC_VERSION_RELEASE == 1 && \ > (PETSC_VERSION_MAJOR < (MAJOR) || \ > (PETSC_VERSION_MAJOR == (MAJOR) && \ > (PETSC_VERSION_MINOR < (MINOR) || \ > (PETSC_VERSION_MINOR == (MINOR) && \ > (PETSC_VERSION_SUBMINOR < (SUBMINOR))))))) > #endif > > ... other stuff for you application > > > > > Thanks, > > Jim > > > > > > On Sat, Jun 15, 2013 at 2:51 PM, Jed Brown <jedbr...@mcs.anl.gov> wrote: > > > >> Yikes, that should be RELEASE==1. Looks like I totally botched this: > >> > >> > >> > https://bitbucket.org/petsc/petsc/commits/03354681f90b4c94467f09fd38f90b774d661d87 > >> > >> Will fix when I have a keyboard. > >> > >> But how can you have this macro with 3.2? > >> On Jun 15, 2013 7:54 AM, "Jim Fonseca" <jefons...@gmail.com> wrote: > >> > >>> Hi, > >>> In http://www.mcs.anl.gov/petsc/petsc-current/include/petscversion.h > >>> there is: > >>> > >>> > >>> > >>> > >>> #define PETSC_VERSION_LT(MAJOR,MINOR,SUBMINOR) \ > >>> (PETSC_VERSION_RELEASE == 0 && \ > >>> (PETSC_VERSION_MAJOR < (MAJOR) || \ > >>> (PETSC_VERSION_MAJOR == (MAJOR) && \ > >>> (PETSC_VERSION_MINOR < (MINOR) || \ > >>> (PETSC_VERSION_MINOR == (MINOR) && \ > >>> (PETSC_VERSION_SUBMINOR < (SUBMINOR))))))) > >>> > >>> > >>> Won't this always be false for release versions? > >>> > >>> We're trying to move from 3.2 and the following is evaluating to true. > (I've put the new additions to petscversion.h into that file in our older > builds). > >>> > >>> #if PETSC_VERSION_GE(3,3,0) > >>> > >>> //we should not get here, but we do > >>> > >>> > >>> when petscversion.h has > >>> > >>> #define PETSC_VERSION_RELEASE 1 > >>> #define PETSC_VERSION_MAJOR 3 > >>> #define PETSC_VERSION_MINOR 2 > >>> #define PETSC_VERSION_SUBMINOR 0 > >>> #define PETSC_VERSION_PATCH 6 > >>> > >>> Thanks, > >>> > >>> Jim > >>> > >>> > >>> -- > >>> Jim Fonseca, PhD > >>> Research Scientist > >>> Network for Computational Nanotechnology > >>> Purdue University > >>> 765-496-6495 > >>> www.jimfonseca.com > >>> > >>> > >>> > > > > > > -- > > Jim Fonseca, PhD > > Research Scientist > > Network for Computational Nanotechnology > > Purdue University > > 765-496-6495 > > www.jimfonseca.com > -- Jim Fonseca, PhD Research Scientist Network for Computational Nanotechnology Purdue University 765-496-6495 www.jimfonseca.com
