[petsc-dev] Regression tests

[Matthew Knepley]

On Thu, Jul 26, 2012 at 2:39 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Thu, Jul 26, 2012 at 2:34 PM, Matthew Knepley <knepley at gmail.com>wrote:
>
>> Well, that's an interesting (and confusing) idea for how it *could* work
>>> some day, but it's not how it currently works.
>>>
>>
>> How the fuck is that confusing? Is this just for the sake of argument.
>> This is how we DESIGNED configure to work
>> and treat logs. Were you absent that day? Do you have a note?
>>
>
> 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.
>
> 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.
>

You do not read it correctly. It operates exactly as everything else. You
move make.log to make.log.bkp, which is what we do now, and
write into make.log. It seems to be writing without moving first.


> 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.
>

In my first message, it says "this is a bug". What is hard about that? What
necessitates 3 replies missing that point?

   Matt


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120726/4bb19479/attachment.html>