<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 5:30 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 12 Dec 2013, Dmitry Karpeyev wrote:<br>
<br>
> On Thu, Dec 12, 2013 at 5:05 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Thu, 12 Dec 2013, Dmitry Karpeyev wrote:<br>
> ><br>
> > > Is there any reason 'master' has PETSC_VERSION equal to the latest patch<br>
> > > release version,<br>
> > > rather than the first upcoming release version?<br>
> ><br>
> > All changes to petscversion.h in maint get merged to master.<br>
> ><br>
> Yes, I see the problem.  I don't necessarily have a (good) solution, short<br>
> of creating<br>
> a separate branch for each patch release (e.g., maint-3.4.3).  Those could<br>
> be ahead<br>
> of maint by a single commit such as those that are currently used to<br>
> increment the patch level.<br>
><br>
> ><br>
> > And 'PETSC_VERSION_RELEASE'  0 vs 1 is supporsed to identify petsc-dev.<br>
> ><br>
> > > Surely, the use of PETSC_VERSION_LT() makes it relatively easy to guard<br>
> > > against API changes in derived software, but it's a bit odd to see<br>
> > > #if PETSC_VERSION_LT(3,5,0)<br>
> > > /* Works for petsc-3.4.x and earlier. */<br>
> > > #else<br>
> > > /* Supposed to work petsc-3.4.x as long as !PETSC_VERSION_RELEASE */<br>
> ><br>
> > It should be 'latest petsc master' here. 3.4.x doesn't have any meaning<br>
> > here..<br>
> ><br>
> Yes, but master today has version number 3.4.3.<br>
<br>
</div>As mentioned 3.4.3 has no baring on master. only PETSC_VERSION_RELEASE==0 is relavent.<br>
<div class="im"><br>
> In some code that depends on PETSc (e.g., libMesh) I have to use guards<br>
> like these:<br>
> #if PETSC_VERSION_LESS_THAN(3,5,0) && PETSC_VERSION_RELEASE<br>
> /* releases petsc-3.4.x and earlier. */<br>
> #else<br>
> /* master */<br>
> #endif<br>
<br>
</div>I don't see a problem here [except for the extra '&&<br>
PETSC_VERSION_RELEASE' which shouldn't be needed.<br>
<div class="im"><br>
<br>
> Note that I can't always use the more succinct PETSC_VERSION_LT(),<br>
> since it doesn't exist before something like petsc-3.3.<br>
<br>
</div>Presumably PETSC_VERSION_LESS_THAN() is the macro you created. Why not<br>
just copy over PETSC_VERSION_LT() exactly as-is [with dependent<br>
macros] - and call it PETSC_VERSION_LESS_THAN() [or equivalent name] -<br>
if you need to maintain compatibility for petsc-3.2 or older.<br></blockquote><div> </div><div>In this particular instance (libMesh) it's a libMesh macro. libMesh doesn't rely on petscversion.h, </div><div>but rather detects the petsc version numbers during configure.  It doesn't use PETSC_VERSION_RELEASE, </div>

<div>so it's not an entirely trivial fix (at least for me).</div><div>I build libmesh against petsc-master fairly regularly, but I don't know how much general interest there is </div><div>in this.  I'm forwarding this to libmesh-devel just in case. </div>

<div><br></div><div>Dmitry.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> I could guard for pesc-3.3<br>
> and then use the shorter macro inside, but that defeats the purpose.<br>
> Meanwhile, these additional PETSC_VERSION_RELEASE clauses look odd.<br>
<br>
</div>I don't understand which part looks odd - and how adding a version<br>
numer to petsc-master helps here.<br>
<span class="HOEnZb"><font color="#888888"><br>
Satish<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> They could be removed after petsc-3.5 has been released, but that's another<br>
> maintenance headache...<br>
><br>
> Dmitry.<br>
><br>
> ><br>
> > Satish<br>
> ><br>
> > > #endif<br>
> > ><br>
> > > Besides, master's "version" changes with every patch release.<br>
> > > It might not be of much practical importance, but looks a bit strange, in<br>
> > > my opinion.<br>
> > > At least intuitively, I think of 'master' as a sort of 'release<br>
> > candidate'<br>
> > > for petsc-3.5.0.<br>
> > > Wouldn't it be natural to name it that way?  Is there a technical reason<br>
> > > not to?<br>
> > ><br>
> > > Dmitry.<br>
> > ><br>
> ><br>
> ><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>