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

[Barry Smith]

   Just because you can do it doesn’t mean you should do it.

   Barry

On Oct 29, 2013, at 2:07 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> 
>  It is not worthy any additional logic in the already messing configure process to save a few downloads.
> 
>   Barry
> 
> 
> On Oct 29, 2013, at 1:59 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
>> On Tue, 29 Oct 2013, Jed Brown wrote:
>> 
>>> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>>  Or simpler just have the —with-clean nuke external packages; makes
>>>>  life easy.  By "store the tarballs in a common place” and SHA1 crap
>>>>  you are making the system more complicated to understand and
>>>>  maintain.
>>> 
>>> People will complain when they have to download the same tarball many
>>> times.  But I don't especially care as long as the builds are done
>>> inside $PETSC_ARCH instead of in a common place.  (This is also useful
>>> when building multiple configurations of PETSc in parallel.)
>> 
>> There is also the issue with git repos to deal with. [presumably the
>> above logic would be slightly different than the tarballs]
>> 
>> We [Jed and I ] also discussed having git repos and corresponding
>> tarballs match - and caching tarballs locally for unreliable external
>> sites. And then using SHA as a way of versioning to eliminate most
>> cases where with-clean would be needed.
>> 
>> Just a note: all these issues are primarily with git users - not
>> petsc-release/tarball users.
>> 
>> Satish
>