<div class="gmail_quote">On Thu, Jul 26, 2012 at 2:34 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Well, that's an interesting (and confusing) idea for how it <b>could</b> work some day, but it's not how it currently works.</div>
</div></blockquote><div><br></div></div><div>
How the fuck is that confusing? Is this just for the sake of argument. This is how we DESIGNED configure to work</div><div>and treat logs. Were you absent that day? Do you have a note?</div></blockquote></div><br><div>Normally make.log is moved to make.log.bkp, overwriting the original make.log.bkp. PETSc uses the symlinks to point to the latest versions of make.log and make.log.bkp, but there is only one level of history.</div>
<div><br></div><div>Now your suggestion here (if I read your statement correctly) was that there would be multiple classes of make.log, with builder2.py buildExample only overwriting make.log, but the make.log.bkp from building the library could only be overwritten after another library build. I think that is massively confusing.</div>
<div><br></div><div>I think it is wrong to reuse the name make.log for both purposes. Regardless, the symlinks are not removed, so make.log output overwrites $PETSC_ARCH/conf/make.log and (the next time you run it) $PETSC_ARCH/conf/make.log.bkp.</div>