<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>Barry:</div>
<div><br>
</div>
<div>Re: "Nobody uses more than two $PETSC_ARCH": We have our regression tests run on a machine with 8 different ones (4 Fortran compilers each with debug and optim). This is using stable releases, but there could be people doing the same with maint I guess.</div>
<div><br>
</div>
<div>Åsmund</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div style="font-size:75%;color:#575757">Sent from my VT-102</div>
</div>
<br>
petsc-dev-request@mcs.anl.gov skrev:<br>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Send petsc-dev mailing list submissions to<br>
        petsc-dev@mcs.anl.gov<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev" target="_BLANK">
https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        petsc-dev-request@mcs.anl.gov<br>
<br>
You can reach the person managing the list at<br>
        petsc-dev-owner@mcs.anl.gov<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of petsc-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re:  [petsc-maint] valgrind detected on   /usr/local/include<br>
      and enabled but header files from this dir        are not added to build<br>
      path (Barry Smith)<br>
   2. Re:  [petsc-maint] valgrind detected on   /usr/local/include<br>
      and enabled but header files from this dir        are not added to build<br>
      path (Jed Brown)<br>
   3. Re:  [petsc-maint] valgrind detected on   /usr/local/include<br>
      and enabled but header files from this dir        are not added to build<br>
      path (Satish Balay)<br>
   5. Re:  [petsc-maint] valgrind detected      on      /usr/local/include<br>
      and enabled but header files from this    dir     are not added to build<br>
      path (Barry Smith)<br>
   6. Re:  [petsc-maint] valgrind detected      on      /usr/local/include<br>
      and enabled but header files from this    dir     are not added to build<br>
      path (Barry Smith)<br>
   7. Re:  [petsc-maint] valgrind detected on   /usr/local/include<br>
      and enabled but header files from this dir        are not added to build<br>
      path (Jed Brown)<br>
   8. Re:  [petsc-maint] valgrind detected on /usr/local/include<br>
      and enabled but header files from this dir are not added to build<br>
      path (Aron Ahmadia)<br>
   9. Re:  [petsc-maint] valgrind detected      on      /usr/local/include<br>
      and enabled but header files from this    dir     are not added to build<br>
      path (Satish Balay)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 29 Oct 2013 13:49:34 -0500<br>
From: Barry Smith <bsmith@mcs.anl.gov><br>
To: Jed Brown <jedbrown@mcs.anl.gov><br>
Cc: For users of the development version of PETSc<br>
        <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on<br>
        /usr/local/include and enabled but header files from this dir   are not<br>
        added to build path<br>
Message-ID: <719930D7-E33C-42CE-8252-2CB5BAEBD3B9@mcs.anl.gov><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
<br>
On Oct 29, 2013, at 9:04 AM, Jed Brown <jedbrown@mcs.anl.gov> wrote:<br>
<br>
> Barry Smith <bsmith@mcs.anl.gov> writes:<br>
>>    Could you please add a ?with-clean (or better name?) option to ./configure that does the $PETSC_ARCH removal business? Then we can just run<br>
>> <br>
>>    $PETSC_ARCH/conf/reconf*.py  ?with-clean<br>
> <br>
> I guess this also has to delete relevant parts of externalpackages to<br>
> make sure the current version of packages get downloaded.<br>
> <br>
> Part of me wants to put all the externalpackages inside $PETSC_ARCH<br>
> because the source is usually smaller than the object files or the<br>
<br>
   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.<br>
<br>
<br>
   Barry<br>
<br>
> compiled binary, so we're not saving anything by unpacking in a common<br>
> location.  We could store the tarballs in a common place and include<br>
> their SHA1 in ${package}.py so that BuildSystem could match the correct<br>
> tarball and unpack it cleanly.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 29 Oct 2013 12:51:57 -0600<br>
From: Jed Brown <jedbrown@mcs.anl.gov><br>
To: Barry Smith <bsmith@mcs.anl.gov><br>
Cc: For users of the development version of PETSc<br>
        <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on<br>
        /usr/local/include and enabled but header files from this dir   are not<br>
        added to build path<br>
Message-ID: <87bo27ucz6.fsf@mcs.anl.gov><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Barry Smith <bsmith@mcs.anl.gov> writes:<br>
>    Or simpler just have the ?with-clean nuke external packages; makes<br>
>    life easy.  By "store the tarballs in a common place? and SHA1 crap<br>
>    you are making the system more complicated to understand and<br>
>    maintain.<br>
<br>
People will complain when they have to download the same tarball many<br>
times.  But I don't especially care as long as the builds are done<br>
inside $PETSC_ARCH instead of in a common place.  (This is also useful<br>
when building multiple configurations of PETSc in parallel.)<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 835 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/dd42a127/attachment-0001.pgp" target="_BLANK">http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/dd42a127/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 29 Oct 2013 13:59:49 -0500 (CDT)<br>
From: Satish Balay <balay@mcs.anl.gov><br>
To: Jed Brown <jedbrown@mcs.anl.gov><br>
Cc: For users of the development version of PETSc<br>
        <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on<br>
        /usr/local/include and enabled but header files from this dir   are not<br>
        added to build path<br>
Message-ID: <alpine.LFD.2.03.1310291353210.3576@mcs.anl.gov><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Tue, 29 Oct 2013, Jed Brown wrote:<br>
<br>
> Barry Smith <bsmith@mcs.anl.gov> writes:<br>
> >    Or simpler just have the ?with-clean nuke external packages; makes<br>
> >    life easy.  By "store the tarballs in a common place? and SHA1 crap<br>
> >    you are making the system more complicated to understand and<br>
> >    maintain.<br>
> <br>
> People will complain when they have to download the same tarball many<br>
> times.  But I don't especially care as long as the builds are done<br>
> inside $PETSC_ARCH instead of in a common place.  (This is also useful<br>
> when building multiple configurations of PETSc in parallel.)<br>
<br>
There is also the issue with git repos to deal with. [presumably the<br>
above logic would be slightly different than the tarballs]<br>
<br>
We [Jed and I ] also discussed having git repos and corresponding<br>
tarballs match - and caching tarballs locally for unreliable external<br>
sites. And then using SHA as a way of versioning to eliminate most<br>
cases where with-clean would be needed.<br>
<br>
Just a note: all these issues are primarily with git users - not<br>
petsc-release/tarball users.<br>
<br>
Satish<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 29 Oct 2013 14:06:16 -0500<br>
From: Barry Smith <bsmith@mcs.anl.gov><br>
To: Jed Brown <jedbrown@mcs.anl.gov><br>
Cc: For users of the development version of PETSc<br>
        <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on<br>
        /usr/local/include and enabled but header files from this dir   are not<br>
        added to build path<br>
Message-ID: <9BC093D9-4FDF-4496-A8BD-260914B949FE@mcs.anl.gov><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
<br>
On Oct 29, 2013, at 1:51 PM, Jed Brown <jedbrown@mcs.anl.gov> wrote:<br>
<br>
> Barry Smith <bsmith@mcs.anl.gov> writes:<br>
>>   Or simpler just have the ?with-clean nuke external packages; makes<br>
>>   life easy.  By "store the tarballs in a common place? and SHA1 crap<br>
>>   you are making the system more complicated to understand and<br>
>>   maintain.<br>
> <br>
> People will complain when they have to download the same tarball many<br>
> times.  But I don't especially care as long as the builds are done<br>
> inside $PETSC_ARCH instead of in a common place.  (This is also useful<br>
> when building multiple configurations of PETSc in parallel.)<br>
<br>
   Besides us, hardly anyone uses more than 2 PETSC_ARCH!  <br>
<br>
   So how about just moving externalpackages into $PETSC_ARCH and don?t build some elaborate scheme that reuses tar balls for a tiny number of people.  In other words a clean truly means clean and gets new tar balls.<br>
<br>
   Barry<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 29 Oct 2013 14:07:31 -0500<br>
From: Barry Smith <bsmith@mcs.anl.gov><br>
To: petsc-dev <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected        on<br>
        /usr/local/include and enabled but header files from this       dir     are not<br>
        added to build path<br>
Message-ID: <C37092D2-4C26-4F1A-91B6-21C8E7408ADC@mcs.anl.gov><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
<br>
  It is not worthy any additional logic in the already messing configure process to save a few downloads.<br>
<br>
   Barry<br>
<br>
<br>
On Oct 29, 2013, at 1:59 PM, Satish Balay <balay@mcs.anl.gov> wrote:<br>
<br>
> On Tue, 29 Oct 2013, Jed Brown wrote:<br>
> <br>
>> Barry Smith <bsmith@mcs.anl.gov> writes:<br>
>>>   Or simpler just have the ?with-clean nuke external packages; makes<br>
>>>   life easy.  By "store the tarballs in a common place? and SHA1 crap<br>
>>>   you are making the system more complicated to understand and<br>
>>>   maintain.<br>
>> <br>
>> People will complain when they have to download the same tarball many<br>
>> times.  But I don't especially care as long as the builds are done<br>
>> inside $PETSC_ARCH instead of in a common place.  (This is also useful<br>
>> when building multiple configurations of PETSc in parallel.)<br>
> <br>
> There is also the issue with git repos to deal with. [presumably the<br>
> above logic would be slightly different than the tarballs]<br>
> <br>
> We [Jed and I ] also discussed having git repos and corresponding<br>
> tarballs match - and caching tarballs locally for unreliable external<br>
> sites. And then using SHA as a way of versioning to eliminate most<br>
> cases where with-clean would be needed.<br>
> <br>
> Just a note: all these issues are primarily with git users - not<br>
> petsc-release/tarball users.<br>
> <br>
> Satish<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 29 Oct 2013 14:08:08 -0500<br>
From: Barry Smith <bsmith@mcs.anl.gov><br>
To: petsc-dev <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected        on<br>
        /usr/local/include and enabled but header files from this       dir     are not<br>
        added to build path<br>
Message-ID: <0C021837-7C75-47D3-9CAC-39D582955549@mcs.anl.gov><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
<br>
   Just because you can do it doesn?t mean you should do it.<br>
<br>
   Barry<br>
<br>
On Oct 29, 2013, at 2:07 PM, Barry Smith <bsmith@mcs.anl.gov> wrote:<br>
<br>
> <br>
>  It is not worthy any additional logic in the already messing configure process to save a few downloads.<br>
> <br>
>   Barry<br>
> <br>
> <br>
> On Oct 29, 2013, at 1:59 PM, Satish Balay <balay@mcs.anl.gov> wrote:<br>
> <br>
>> On Tue, 29 Oct 2013, Jed Brown wrote:<br>
>> <br>
>>> Barry Smith <bsmith@mcs.anl.gov> writes:<br>
>>>>  Or simpler just have the ?with-clean nuke external packages; makes<br>
>>>>  life easy.  By "store the tarballs in a common place? and SHA1 crap<br>
>>>>  you are making the system more complicated to understand and<br>
>>>>  maintain.<br>
>>> <br>
>>> People will complain when they have to download the same tarball many<br>
>>> times.  But I don't especially care as long as the builds are done<br>
>>> inside $PETSC_ARCH instead of in a common place.  (This is also useful<br>
>>> when building multiple configurations of PETSc in parallel.)<br>
>> <br>
>> There is also the issue with git repos to deal with. [presumably the<br>
>> above logic would be slightly different than the tarballs]<br>
>> <br>
>> We [Jed and I ] also discussed having git repos and corresponding<br>
>> tarballs match - and caching tarballs locally for unreliable external<br>
>> sites. And then using SHA as a way of versioning to eliminate most<br>
>> cases where with-clean would be needed.<br>
>> <br>
>> Just a note: all these issues are primarily with git users - not<br>
>> petsc-release/tarball users.<br>
>> <br>
>> Satish<br>
> <br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 29 Oct 2013 13:12:30 -0600<br>
From: Jed Brown <jedbrown@mcs.anl.gov><br>
To: Barry Smith <bsmith@mcs.anl.gov><br>
Cc: For users of the development version of PETSc<br>
        <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on<br>
        /usr/local/include and enabled but header files from this dir   are not<br>
        added to build path<br>
Message-ID: <8761sfuc0x.fsf@mcs.anl.gov><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Barry Smith <bsmith@mcs.anl.gov> writes:<br>
>    Besides us, hardly anyone uses more than 2 PETSC_ARCH!<br>
<br>
And here I have 60 on one machine.  It might be time to clean up a<br>
little.<br>
<br>
>    So how about just moving externalpackages into $PETSC_ARCH and<br>
>    don?t build some elaborate scheme that reuses tar balls for a tiny<br>
>    number of people.  In other words a clean truly means clean and<br>
>    gets new tar balls.<br>
<br>
That sounds good to me.<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 835 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/248da1e6/attachment-0001.pgp" target="_BLANK">http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/248da1e6/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 29 Oct 2013 15:15:41 -0400<br>
From: Aron Ahmadia <aron@ahmadia.net><br>
To: Jed Brown <jedbrown@mcs.anl.gov><br>
Cc: For users of the development version of PETSc<br>
        <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected on<br>
        /usr/local/include and enabled but header files from this dir are not<br>
        added to build path<br>
Message-ID:<br>
        <CAPhiW4gmZwD-yrSM8W3nd7Jeww7F23TGPty0ae8kRyj_bN+idw@mail.gmail.com><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
> >    So how about just moving externalpackages into $PETSC_ARCH and<br>
> >    don?t build some elaborate scheme that reuses tar balls for a tiny<br>
> >    number of people.  In other words a clean truly means clean and<br>
> >    gets new tar balls.<br>
><br>
> That sounds good to me.<br>
><br>
<br>
I don't expect (or really want) any more complexity out of PETSc.  +1 from<br>
here.<br>
<br>
A<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/2b76fc4c/attachment-0001.html" target="_BLANK">http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131029/2b76fc4c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 29 Oct 2013 14:16:14 -0500 (CDT)<br>
From: Satish Balay <balay@mcs.anl.gov><br>
To: Barry Smith <bsmith@mcs.anl.gov><br>
Cc: petsc-dev <petsc-dev@mcs.anl.gov><br>
Subject: Re: [petsc-dev] [petsc-maint] valgrind detected        on<br>
        /usr/local/include and enabled but header files from this       dir     are not<br>
        added to build path<br>
Message-ID: <alpine.LFD.2.03.1310291412460.3576@mcs.anl.gov><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
I mistated one thing.<br>
<br>
The git-url usage in pacakge.py spills over to tarball users aswell.<br>
<br>
Now to have consistant tarballs wrt git repo - we have to migrate all<br>
tarball urls to tarballs from the git repo hosting site. [and not host<br>
at ftp.mcs.anl.gov]<br>
<br>
But this is unreliable [the last I checked with elemental at github -<br>
git failed frequently - but it was giving out taballs more reliably]<br>
<br>
satish<br>
<br>
On Tue, 29 Oct 2013, Barry Smith wrote:<br>
<br>
> <br>
>    Just because you can do it doesn?t mean you should do it.<br>
> <br>
>    Barry<br>
> <br>
> On Oct 29, 2013, at 2:07 PM, Barry Smith <bsmith@mcs.anl.gov> wrote:<br>
> <br>
> > <br>
> >  It is not worthy any additional logic in the already messing configure process to save a few downloads.<br>
> > <br>
> >   Barry<br>
> > <br>
> > <br>
> > On Oct 29, 2013, at 1:59 PM, Satish Balay <balay@mcs.anl.gov> wrote:<br>
> > <br>
> >> On Tue, 29 Oct 2013, Jed Brown wrote:<br>
> >> <br>
> >>> Barry Smith <bsmith@mcs.anl.gov> writes:<br>
> >>>>  Or simpler just have the ?with-clean nuke external packages; makes<br>
> >>>>  life easy.  By "store the tarballs in a common place? and SHA1 crap<br>
> >>>>  you are making the system more complicated to understand and<br>
> >>>>  maintain.<br>
> >>> <br>
> >>> People will complain when they have to download the same tarball many<br>
> >>> times.  But I don't especially care as long as the builds are done<br>
> >>> inside $PETSC_ARCH instead of in a common place.  (This is also useful<br>
> >>> when building multiple configurations of PETSc in parallel.)<br>
> >> <br>
> >> There is also the issue with git repos to deal with. [presumably the<br>
> >> above logic would be slightly different than the tarballs]<br>
> >> <br>
> >> We [Jed and I ] also discussed having git repos and corresponding<br>
> >> tarballs match - and caching tarballs locally for unreliable external<br>
> >> sites. And then using SHA as a way of versioning to eliminate most<br>
> >> cases where with-clean would be needed.<br>
> >> <br>
> >> Just a note: all these issues are primarily with git users - not<br>
> >> petsc-release/tarball users.<br>
> >> <br>
> >> Satish<br>
> > <br>
> <br>
> <br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
petsc-dev mailing list<br>
petsc-dev@mcs.anl.gov<br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev" target="_BLANK">https://lists.mcs.anl.gov/mailman/listinfo/petsc-dev</a><br>
<br>
<br>
End of petsc-dev Digest, Vol 58, Issue 61<br>
*****************************************<br>
</div>
</span></font>
</body>
</html>