On Thu, Dec 12, 2013 at 5:30 PM, Satish Balay <[email protected]> wrote:
> On Thu, 12 Dec 2013, Dmitry Karpeyev wrote: > > > On Thu, Dec 12, 2013 at 5:05 PM, Satish Balay <[email protected]> wrote: > > > > > On Thu, 12 Dec 2013, Dmitry Karpeyev wrote: > > > > > > > Is there any reason 'master' has PETSC_VERSION equal to the latest > patch > > > > release version, > > > > rather than the first upcoming release version? > > > > > > All changes to petscversion.h in maint get merged to master. > > > > > Yes, I see the problem. I don't necessarily have a (good) solution, > short > > of creating > > a separate branch for each patch release (e.g., maint-3.4.3). Those > could > > be ahead > > of maint by a single commit such as those that are currently used to > > increment the patch level. > > > > > > > > And 'PETSC_VERSION_RELEASE' 0 vs 1 is supporsed to identify petsc-dev. > > > > > > > Surely, the use of PETSC_VERSION_LT() makes it relatively easy to > guard > > > > against API changes in derived software, but it's a bit odd to see > > > > #if PETSC_VERSION_LT(3,5,0) > > > > /* Works for petsc-3.4.x and earlier. */ > > > > #else > > > > /* Supposed to work petsc-3.4.x as long as !PETSC_VERSION_RELEASE */ > > > > > > It should be 'latest petsc master' here. 3.4.x doesn't have any meaning > > > here.. > > > > > Yes, but master today has version number 3.4.3. > > As mentioned 3.4.3 has no baring on master. only PETSC_VERSION_RELEASE==0 > is relavent. > > > In some code that depends on PETSc (e.g., libMesh) I have to use guards > > like these: > > #if PETSC_VERSION_LESS_THAN(3,5,0) && PETSC_VERSION_RELEASE > > /* releases petsc-3.4.x and earlier. */ > > #else > > /* master */ > > #endif > > I don't see a problem here [except for the extra '&& > PETSC_VERSION_RELEASE' which shouldn't be needed. > > > > Note that I can't always use the more succinct PETSC_VERSION_LT(), > > since it doesn't exist before something like petsc-3.3. > > Presumably PETSC_VERSION_LESS_THAN() is the macro you created. Why not > just copy over PETSC_VERSION_LT() exactly as-is [with dependent > macros] - and call it PETSC_VERSION_LESS_THAN() [or equivalent name] - > if you need to maintain compatibility for petsc-3.2 or older. > In this particular instance (libMesh) it's a libMesh macro. libMesh doesn't rely on petscversion.h, but rather detects the petsc version numbers during configure. It doesn't use PETSC_VERSION_RELEASE, so it's not an entirely trivial fix (at least for me). I build libmesh against petsc-master fairly regularly, but I don't know how much general interest there is in this. I'm forwarding this to libmesh-devel just in case. Dmitry. > > I could guard for pesc-3.3 > > and then use the shorter macro inside, but that defeats the purpose. > > Meanwhile, these additional PETSC_VERSION_RELEASE clauses look odd. > > I don't understand which part looks odd - and how adding a version > numer to petsc-master helps here. > > Satish > > > They could be removed after petsc-3.5 has been released, but that's > another > > maintenance headache... > > > > Dmitry. > > > > > > > > Satish > > > > > > > #endif > > > > > > > > Besides, master's "version" changes with every patch release. > > > > It might not be of much practical importance, but looks a bit > strange, in > > > > my opinion. > > > > At least intuitively, I think of 'master' as a sort of 'release > > > candidate' > > > > for petsc-3.5.0. > > > > Wouldn't it be natural to name it that way? Is there a technical > reason > > > > not to? > > > > > > > > Dmitry. > > > > > > > > > > > > > >
