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