[petsc-dev] [petsc-maint] valgrind detected on /usr/local/include and enabled but header files from this dir are not added to build path

Matthew Knepley knepley at gmail.com
Tue Oct 29 16:07:48 CDT 2013


On Tue, Oct 29, 2013 at 4:02 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Satish Balay <balay at mcs.anl.gov> writes:
>
> > On Tue, 29 Oct 2013, Jed Brown wrote:
> >
> >> Satish Balay <balay at mcs.anl.gov> writes:
> >> > If you look at the current configure.log - its after fortran compiler
> >> > detection.
> >> >
> >> > Currently the dependencies [for PETSC_ARCH] are:
> >> >
> >> >     self.petscdir = framework.require('PETSc.utilities.petscdir',
> self)
> >> >     self.languages = framework.require('PETSc.utilities.languages',
> self)
> >> >     self.compilerFlags = framework.require('config.compilerFlags',
> self)
> >> >
> >> > so it need to get that far before PETSC_ARCH can be set/used..
> >>
> >> Okay, but why does it have to go that far?
> >
> > Because of the current dependency "config.compilerFlags ->
> config.setCompilers"
> > The following change moves the arch.py usage up earlier. If
> configureInstallationMethod()
> > can be moved out of petscdir.py - then it can probably move even
> earlier..
>
> Matt is the one with vision about BuildSystem dependencies so I'll leave
> it to him to comment.


I see fooling with dependencies as a good thing in general to simplify
things, but having not
much to do with what Jed wants. We can easily buffer till kingdom come.

What needs to be done is to overload write() for the logger, so that if no
file is open it buffers,
and then when a file is set, the contents get dumped in.


> > Ideally the buffered stuff for configure.log should be only a few
> > lines - without any signigicant tests before it..
>
> Yeah, so that if it fails, the error message will be short enough that
> people can copy and paste it.
>
> > BTW: there is also etags/fortranstub stuff that configure does - that
> > can cause problems with simultaneous builds. So they should be done
> > with some locking scheme?
>
> No locking, just commit the results atomically.  That means write a
> temporary file and rename it to replace the existing file.  (Or checksum
> and just delete the tmp file if they match, so that modification times
> don't change.)
>

This is not good enough for the stubs.

   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/20131029/80c99860/attachment.html>


More information about the petsc-dev mailing list